¿Cuál es la regla de oro para exponer métodos de clase encapsulada?

Question

Considere la siguiente analogía: Si tenemos una clase: "Coche" podemos esperar que tenga una instancia de "Motor" en ella. Como en: "El automóvil tiene un motor". De manera similar, en la clase "Engine" esperaríamos una instancia de "Starting System" o "Cooling System", cada uno con sus subcomponentes apropiados.

Por la naturaleza de la encapsulación, ¿no es cierto que el automóvil "HAS-A" tiene "manguera del radiador" y el motor?

Por lo tanto, es OO apropiado para hacer algo como esto:

public class Car { 
    private Engine _engine; 

    public Engine getEngine() { 
     return _engine; 
    } 

    // is it ok to use 'convenience' methods of inner classes? 
    // are the following 2 methods "wrong" from an OO point of view? 
    public RadiatorHose getRadiatorHose() { 
     return getCoolingSystem().getRadiatorHose(); 
    } 

    public CoolingSystem getCoolingSystem() { 
     return _engine.getCoolingSystem(); 
    } 
} 

public class Engine { 
    private CoolingSystem _coolingSystem; 

    public CoolingSystem getCoolingSystem() { 
     return _coolingSystem; 
    } 
} 

public class CoolingSystem { 
    private RadiatorHose _radiatorHose; 

    public RadiatorHose getRadiatorHose() { 
     return _radiatorHose; 
    } 
} 

public class RadiatorHose {//... 
} 

Answer 1

Compruebe en el Law of Demeter.

Answer 2

Al llegar dentro de otras clases encapsuladas que está buscando problemas. El objetivo de la encapsulación es que no necesita saber cómo se implementa la función, sino qué hace y cómo acceder a ella.
Si tuviera que cambiar la forma en que el sistema de refrigeración y la manguera del radiador interactuaban, el motor no debería verse afectado en absoluto. En el caso en el que expongas, esto causaría problemas. Esta realmente no es la POO correcta, y causará problemas en el futuro.

Answer 3

Como regla general, primero puede usar el lenguaje de la naturaleza para describir las relaciones entre los componentes, que últimamente se representan como clases, y luego usar ciertos diagramas para presentar estas relaciones. Si dos componentes están conectados en sus diagramas, deberían tener cierta conexión en su programa. En su caso, puede determinar si "motor" es una instancia de "automóvil", y "sistema de enfriamiento" es una instancia de "motor" al observar si hay conexiones entre estos componentes en su diagrama. (Este proceso es en realidad la intuición del lenguaje de modelado OO como UML.)

De hecho, no veo nada incorrecto en su código. No soy un automovilista, por lo que podría estar equivocado de entender el sistema. Pero si el motor de un automóvil real necesita un sistema de refrigeración, creo que lo que estás haciendo es correcto. Sí, la clase "motor" llama a la propiedad de la clase "sistema de enfriamiento", pero debido a que el "motor" usa el método público para invocar al "sistema de enfriamiento", es la manera correcta. Una vez más, no conozco el sistema de automóvil real, por lo que podría estar equivocado en este diseño en particular.

Answer 4

Aquí es una muy buena (y bastante corta) de papel en la Ley de Demeter llamado The Paperboy, la cartera, y la ley del Demeter:

http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf

Cuando, has leído deberías leer este breve artículo que detalla cuántas personas malinterpretan la ley del demeter. Al hacer esto, el artículo actúa como una muy buena explicación. ¡Se llama acertadamente "La Ley de Demeter no es un ejercicio de contar puntos"!

http://haacked.com/archive/2009/07/14/law-of-demeter-dot-counting.aspx