编程语言突破.doc

多年以前（早在1992年），我加入了一个疯狂的科研项目（skunkworks），该项目使用了一种另类的编程语言——Smalltalk。当时“面向对象”这个术语才刚兴起不久。作为“面向对象”的顾问，报酬非常可观。很多人自以为这就是新的对象派别的全部内容。在这5年后，Alan Kay说了这句话：“我发明了‘面向对象编程’这个术语，但{Java和C++}跟我所知道的有所不同”。（”I invented the term ‘Object Oriented Programming’ and this {Java and C++} is not what I had in mind.”） 在加入这个奇特的小组，使用这种奇怪的编程语言不久之后，我依然对实例变量、类变量、类实例变量之间的差别感到困惑。我参加了来自ParcPlace的Russ Pencin的培训课程。他说了一些当时我很不喜欢的东西。尽管不明白金玉良言当中的要点，但我还是努力跟上进度。这需要多年的经验才能渐渐体会其中的价值。建议是？ 不要使用‘er’结尾的对象（Don’t make objects that end with ‘er’.） 没错。面向对象编程（OOP）的模式在我们称之为“程序化编程”的文化当中活力十足。现在我们没有过多地谈论这两种模式之间的对比。也许一部分是因为面向对象语言现在俯拾即是。面向对象编程流派，在众多派别中脱颖而出。可惜的是，我经常回想起我在2000年左右听过 Adele Goldberg的演讲：“现在我们有很多面向对象编程技术，但就没有那么多面向对象编程的程序员”。假如我有一个建议想转告给一群有志成为面向对象程序员的人，那应该是Russ提供的一句金玉良言：“不要使用‘er’结尾的对象。” 这名字到底意味着什么呢？为什么值得人们对它如此兴奋？多年以后我发现，面向对象编程的精髓在于将行为绑定在数据上。在你还没成为他们无归属组织的重要一员时，程序就还是由行为和数据构成。在典型的结构化程序设计之中，我们将精力集中在行为（动词）上，然后弄清楚我们需要哪些数据（名词）才能执行。总而言之，我们将数据绑定在行为上。但在面向对象程序设计之中，我们将程序的中心用名词和数据表示，然后弄清楚我们要将哪些行为绑定在他们之上，希望这些我们想要解决的问题能够在突发的行为中得到答案。 最近我觉得有一个更好的名字来形容一位同事差不多都插手过的每一个“er”对象例子。 给例子起一个更好的名字会让设计更加具有独立性，代码的关联性更少，总之，更加面向对象。这不是硬性规定，不过这会让很多例子得到改善。 就拿某种“装载程序模块”来说吧，重点在于它的工作单元。模块有许多实例变量，参数，也许还有很多到处传输的数据。如今，取而代之的是LoadRecord和LoadStream。我有理由相信，你们最终使用的工具，更类似于面向对象编程创始人心中设想的模样。我们想要创造可以描述的对象，然后将某些行为绑定在它上面，而不是将焦点集中在它的行为上，然后弄清楚他们的行为需要哪些数据。 某些以前学过的用er结尾的对象已经绝迹多年 管理者（Manager）——每当我遇到一位管理者时，我就会感到担忧。大家没有跟我说它的含义，却早早地告诉我它的职能。它是注册表吗？那就叫它注册表吧。是历史记录还是日志？就那样称呼吧。是工厂吗？就那样称呼吧。 控制器（Controller）——我在过去20年内只做过一个上等的控制器对象，它是一个象征着现实世界对象的BallastVoltageController接口。事实上，世界上每一个简单MVC的执行与控制器的不同作用本应告诉我们这个构想相当协调的事情。 组织者（Organizer 以及许多类似的团体）——焦点在于他们的职能。这是一个用来说明让众多这种‘ers’对象转化为组织极其简单的不错例子。就把它们称为组织吧。现在我们来关注它们的内容。 分析器/渲染器/（Analyzer/Renderer）/等等——“劳动者”对象中定义清晰的例子。假设它们是用来分析/渲染/等等。 生成器/加载器/阅读器/编写器/（Builder/Loader/Reader/Writer/）等等——把焦点从被操控的对象身上挪开，它们自身往往承担着重大的责任。 这样一条路线规则也会有很多例外 有许多以‘er’结尾的名词。注册表、边框、字母、数字。如果真的是一个名词的话，那就好了。 有很多‘er’结尾的单词，尽管重点在于它们的行为上，也变得很常见了，所以我们最好至少在一定程度上维持这种情况。分部程序，编译器，浏览器。 当你试图建立一个以‘er’结尾的域对象模型时，我可以拿比较熟悉的人员管理域作例子，它可以提升个人素质，使人具有管理行为。 你的经历可能会有所不同，我相信有很多人持反对意见。直到你适应了这种心态一段时间之后，你