Smalltalk 中的单一职责
如果单一职责原则适用于OOP，并且smalltalk（以及ruby）被视为一个大多数OO语言中为什么Object类可以响应这么多消息？
仅来自Object methodDict explore的一些内容：
- 检查、探索、浏览、打印：on:
- accept（所有对象上的访问者模式？）
- copy、deepCopy、join、joinTo、at:、at:modify:
- asString ，asFunction，asOrderedCollection（为什么不也是asSet？）
- 海边的：asLink，asJson，asJavascript
这不是对象的责任（例如用户域模型应该只对其私人消息，付款等感兴趣）
编辑：< /strong> 其中一些是有意义的（asString、asOrderedCollection、accept、notify），而另一些则看起来很奇怪（at:、asFunction、deepCopy、join、joinTo）
If the Single Responsibility Principle applies to OOP and smalltalk (&ruby as well) is considered as one of the most OO languages why can Object class respond to so many messages?
Just a few from Object methodDict explore:
- inspect, explore, browse, print: on:
- accept (visitor pattern on all objects?)
- copy, deepCopy, join, joinTo, at:, at: modify:
- asString, asFunction, asOrderedCollection (why not asSet also?)
- seaside ones: asLink, asJson, asJavascript
It is not object's responsibility (for example user domain model should be interested only in its private messages, payments, etc.)
EDIT: some of them are meaningful (asString, asOrderedCollection, accept, notify) while others seems pretty weird (at:, asFunction, deepCopy, join, joinTo)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您必须考虑 Smalltalk 的模块化功能。也就是说，方法定义独立于类定义，因此
Object上的方法可以与它们相关的应用程序打包（例如，Seaside）。这些扩展方法不是基本系统的一部分，因此它们只是从它们所属的包的角度向它们的类添加职责。其中许多方法都是简单的双调度点：如果anObject asFoo只是委托给Foo fromObject: anObject，我不会说它给类增加了太多责任。像
inspect、copy、deepCopy这样的反射方法在概念上在Object上占有一席之地，但我同意有更好的方法反射架构（镜像）。现在，Smalltalk 可能是一个具有美丽原则的理想选择，但您必须对特定的实现持保留态度:)
Smalltalk 系统有发展成为大型整体系统的趋势，因为更改基本系统非常容易，而且因为它人们倾向于将映像用作开发工件，从而绕过持续集成的良好实践。最后，许多这些有趣的班级责任都是由于历史/现实原因造成的； Squeak 尤其如此，因为它主要是作为快速多媒体实验的平台而开发的，而不是用于软件工程教育或行业目的（Pharo 的目标是）。
You have to consider the modularity features of Smalltalk. Namely, method definitions are independent from class definitions, so methods on
Objectcan be packaged with the application they relate to (e.g., Seaside). These extension methods are not part of the base system, so they only add responsibilities to their class from the point of view of the package they belong to. Many of these methods are simple double-dispatch points: ifanObject asFoosimply delegates toFoo fromObject: anObject, I wouldn't say it adds much responsibility to the class.Reflective methods like
inspect,copy,deepCopyconceptually have their place onObject, but I agree that there are better architectures for reflection (Mirrors).Now, Smalltalk might be an ideal with beautiful principles, but you have to take particular implementations with a grain of salt :)
Smalltalk systems have a tendency to evolve into big monolithic systems, because it's so easy to change the base system, and because it's tempting to use the image as a development artifact, bypassing good practices of continuous integration. In the end, a lot of these funny class responsibilities are due to historical/practical reasons; this is especially true of Squeak, because it was primarily developed as a platform for fast multimedia experimentation, rather than for software engineering education or industry purposes (which Pharo aims to be).
有几个原因：
本质上，所有这些消息代表了对象可以执行的所有操作，并且您可以执行很多操作。
A few reasons:
Essentially, all these messages represent everything an object can do, and there's a lot of things you can do.
因为在 Smalltalk 中 - 一切都是一个对象，并且根 Object 类本质上必须管理所有系统行为，包括类层次结构（因为所有类都是对象）和元类层次结构。
权力越大，责任越大。
在其他系统中，对象只是整个系统的子域，对象不必做这么多，因此不需要被赋予这么多命名的职责。
Because in Smalltalk - everything is an object, and the root Object class essentially has to govern all system behaviour, including the Class hierarchy (as all Classes are objects) and the Metaclass hierarchy.
With great power comes great responsibility.
In other systems, where the objects are simply a subdomain of the entire system, Object does not have to do so much, and so does not need to be given so many named responsibilities.