Single responsibility in smalltalk

Question

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)

Answer 1

You have to consider the modularity features of Smalltalk. Namely, method definitions are independent from class definitions, so methods on Object can 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: if anObject asFoo simply delegates to Foo fromObject: anObject, I wouldn't say it adds much responsibility to the class.

Reflective methods like inspect, copy, deepCopy conceptually have their place on Object, 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).

Answer 2

A few reasons:

• Object and ProtoObject are the basis of Smalltalk's object model, so it's normal that they have big responsibilities, like taking care of copy, serialization, etc.
• The law of Demeter may be more important here: who will take care of these functions, if not the Object itself?
• A lot of these functions are there for debugging and representation purposes. You could work without browse, explore and inspect (but they're really useful).

Essentially, all these messages represent everything an object can do, and there's a lot of things you can do.