Вы должны учитывать особенности модульности Smalltalk. А именно, определения методов не зависят от определений классов , поэтому методы в Object могут быть упакованы с приложением, к которому они относятся (например, Seaside). Эти методы расширения не являются частью базовой системы, поэтому они только добавляют обязанности к своему классу с точки зрения пакета, к которому они принадлежат. Многие из этих методов являются простыми точками двойной отправки: если anObject asFoo просто делегирует Foo fromObject: anObject, я бы не сказал, что это добавляет большую ответственность классу.
Рефлексивные методы, такие как inspect, copy, deepCopy, концептуально имеют свое место в Object, но я согласен, что существуют более эффективные архитектуры для отражения ( Mirrors ).
Теперь, Smalltalk может быть идеалом с прекрасными принципами, но вы должны принять конкретные реализации с недоверием:)
Системы Smalltalk имеют тенденцию эволюционировать в большие монолитные системы, потому что базовую систему легко изменить, и потому что заманчиво использовать изображение в качестве артефакта разработки, минуя передовые методы непрерывной интеграции. В конце концов, многие из этих забавных классных обязанностей обусловлены историческими / практическими причинами; это особенно верно в отношении Squeak, потому что он в первую очередь разрабатывался в качестве платформы для быстрых мультимедийных экспериментов, а не для обучения в области разработки программного обеспечения или в промышленных целях (что и стремится Pharo).