Responsabilidad individual en smalltalk

Question

Si el Single Responsibility Principle se aplica a OOP y smalltalk (& ruby ​​también) se considera como uno de los lenguajes más OO ¿por qué la clase Object puede responder a tantos mensajes?

Sólo unos pocos de Object methodDict explore:

• inspeccionar, explorar, navegar, imprimir: en:
• aceptar (? Patrón de visitante en todos los objetos)
• copia, deepCopy, unir, joinTo, por lo :, en: modificar:
• AsString, asfunction, asOrderedCollection (¿por qué no activos también?)
• los mar: Aslink, asJson, asJavascript

No es objeto de responsabilidad (por ejemplo, modelo de dominio de usuario debe estar interesado sólo en sus mensajes privados, pagos, etc.)

EDIT: algunos de ellos son significativos (AsString, asOrderedCollection, aceptar, notificar), mientras que otros parece bastante raro (en :, asfunction, deepCopy, unir, joinTo)

Answer 1

Debe tener en cuenta las características de modularidad de Smalltalk. A saber, las definiciones de métodos son independientes de las definiciones de clase, por lo que los métodos en Object se pueden empaquetar con la aplicación a la que se refieren (por ejemplo, Seaside). Estos métodos de extensión no son parte del sistema base, por lo que solo agregan responsabilidades a su clase desde el punto de vista del paquete al que pertenecen. Muchos de estos métodos son simples puntos de doble envío: si anObject asFoo simplemente delega en Foo fromObject: anObject, no diría que agrega mucha responsabilidad a la clase.

métodos reflectantes como inspect, copy, deepCopy conceptualmente tienen su lugar en Object, pero estoy de acuerdo que hay mejores arquitecturas para la reflexión (Mirrors).

Ahora, Smalltalk puede ser un ideal con hermosas principios, pero hay que tener implementaciones particulares con un grano de sal :)

sistemas Smalltalk tienen una tendencia a evolucionar hacia sistemas monolíticos grandes, porque es muy fácil cambie el sistema base y porque es tentador usar la imagen como un artefacto de desarrollo, evitando las buenas prácticas de integración continua.Al final, muchas de estas divertidas responsabilidades de clase se deben a motivos históricos/prácticos; Esto es especialmente cierto para Squeak, ya que se desarrolló principalmente como una plataforma para la experimentación multimedia rápida, en lugar de para la educación en ingeniería de software o para fines industriales (lo que Pharo pretende ser).

Answer 2

algunas razones:

• objeto y ProtoObject son la base del modelo de objetos de Smalltalk, así que es normal que tienen grandes responsabilidad como el cuidado de la copia, la serialización, etc.
• The law of Demeter pueden ser más importantes aquí: ¿quién se encargará de estas funciones, sino el Objeto mismo?
• Muchas de estas funciones se utilizan con fines de depuración y representación. Podrías trabajar sin navegar, explorar e inspeccionar (pero son realmente útiles).

Básicamente, todos estos mensajes representan todo lo que un objeto puede hacer, y hay muchas cosas que puede hacer.

Answer 3

Porque en Smalltalk - todo es un objeto, y la clase de objeto raíz esencialmente tiene que gobernar todo el comportamiento del sistema, incluida la jerarquía de clases (ya que todas las clases son objetos) y la jerarquía de metaclase.

Con gran potencia viene una gran responsabilidad.

En otros sistemas, donde los objetos son simplemente un subdominio de todo el sistema, Object no tiene que hacer mucho, por lo que no necesita tantas responsabilidades.