我一直在阅读《 Smalltalk的早期历史》,并且提到了“分配”,这使我质疑其含义:
尽管OOP来自许多动机,但其中两个是核心。大型方案是为包含细节隐藏的复杂系统找到一种更好的模块方案,而小型方案是找到一种更灵活的分配方案,然后尝试将其彻底消除。
(从1960-66年开始-早期的OOP和六十年代的其他形成性思想,第一部分)
我从Simula得到的是,您现在可以用目标替换绑定和分配。您希望任何程序员做的最后一件事就是内部状态混乱,即使以图形方式呈现也是如此。相反,应该将对象呈现为更适合用作动态组件的更高级别行为的站点。(...)不幸的是,当今所谓的“面向对象程序设计”中的大部分只是带有奇特构造的旧式程序设计。许多程序现在都通过“昂贵的附加程序”来完成“分配样式”操作。
(摘自“面向对象”样式,第IV节)
我将目的解释为对象是外观,而目的是在对象上设置实例变量(即“赋值”)的任何方法(或“消息”)都违反了目的,我是否正确?第四节中的以下两个陈述似乎支持了这种解释:
一起使用的四种技术-持久状态,多态性,实例化和作为目标的方法-占据了很大的力量。这些都不要求使用“面向对象的语言”-ALGOL 68几乎可以转变为这种样式-OOPL只是将设计师的思想集中在一个特定的富有成果的方向上。但是,正确执行封装不仅是对状态抽象的承诺,而且是从编程中消除面向状态的隐喻的承诺。
...和:
分配语句(甚至是抽象的语句)表达了非常低级的目标,需要更多的目标才能完成任务。通常,我们不希望程序员弄乱状态,无论是否模拟。
可以这样说,鼓励不透明,不可变的实例吗?还是不鼓励直接改变状态?举例来说,如果我有一个BankAccount
类,它的确定有GetBalance
,Deposit
和Withdraw
实例方法/消息; 只需确保没有SetBalance
实例方法/消息?