¿Cómo se aplica la Ley de Demeter a los sistemas orientados a objetos con respecto al acoplamiento y la cohesión? [cerrado]

¿Cómo se aplica la Ley de Demeter a los sistemas orientados a objetos con acoplamiento y cohesión?

Estaba leyendo un libro "Desarrollo de software y práctica profesional" y encontré el capítulo sobre LoD, y tenía curiosidad acerca de cómo se aplica ese principio en los sistemas orientados a objetos.

Según Emerson Macedo, la Ley de Deméter establece lo siguiente:

• Cada unidad debe tener un conocimiento limitado sobre otras unidades: solo unidades "estrechamente" relacionadas con la unidad actual.
• Cada unidad solo debe hablar con sus amigos; No hables con extraños.
• Solo habla con tus amigos inmediatos.

Esto corresponde directamente al principio de bajo acoplamiento como se supone que las unidades (u objetos), al igual que arriba:

• No estar estrechamente unidos entre sí. Solo los más cercanos son.
• Cada uno solo debe hablar con sus colaboradores y no con los colaboradores del colaborador.
• Solo hable con un objeto colaborador inmediato

Una de las formas más bajas de acoplamiento es el paso de mensajes, es decir, los datos se comparten entre objetos a través de llamadas a métodos con parámetros.

Además, por lo que puedo ver, la Ley de Deméter no corresponde directamente con el principio de alta cohesión, ya que eso solo establece que los objetos mismos deben saber qué datos poseen ellos mismos. Un objeto con baja cohesión tiene miembros de datos que no está utilizando con frecuencia en sus propios métodos. Se trata más del contenido de un objeto que de sus relaciones y objetos de colaboración.

Acoplamiento, simplificado

Cuando un objeto llama a un método, propiedad, etc. de otro objeto, decimos que los objetos están acoplados. Lo llamamos acoplamiento porque ahora la persona que llama no puede cambiar nada sobre su propio método / accesorio. sin romper la llamada .

Por lo tanto, cuanto más el acoplamiento - métodos, accesorios. - Cuanto más difícil sea cambiar el código de la persona que llama sin romper todo el código que lo usa.

contemplando el acoplamiento

• Haciendo referencia incluso a un solo accesorio, el método combina dos objetos.
• Obviamente, el acoplamiento es necesario para crear software.
• Dada la naturaleza del "paso de bloqueo" del acoplamiento, queremos limitarlo y aislarlo. Este objetivo simplemente va junto con el desarrollador de software general. principios
• Cuantos menos objetos tengamos con qué hablar, menor será el acoplamiento.
• Si necesito hacer, digamos, 20 llamadas a métodos diferentes, el acoplamiento es menor si las 20 llamadas son a una clase / objeto, viceversa, esos mismos métodos se extienden sobre varias clases / objetos.

La mayoría del conocimiento causa un acoplamiento loco

Aquí tenemos un Employeeque tiene un Personque tiene una 'Dirección'

public class Employee {
    public Person me = new Person();
}
public class Person {
    public Address home = new Address();
}
public class Address {
    public string street;
} 

Para llegar a la calle Debo llamar: myEmployee.me.home.street. Esto es 180 grados opuesto al principio de menor conocimiento. Tengo que saber sobre el funcionamiento interno, la estructura compuesta, de la Employee, Persony Addressclases.

Este diseño de clase defectuoso me obliga a conocer todas esas clases y, por lo tanto, myEmployee.me.home.streetme une (el objeto llamante) a no menos de 3 clases, ¡para obtener una sola propiedad!

Menos conocimiento salva el día

Si hablo solo con la Employeeclase, estoy aplicando el principio de menor conocimiento per se, y al hacerlo, automáticamente limitamos el acoplamiento a solo esa clase, y al mismo tiempo aislamos el acoplamiento a esa clase.

Al agregar todas las propiedades necesarias en la Employeeclase, arreglamos el acoplamiento.

así

public class Employee {
    public Person me = new Person();
    public string street { return me.home.street; }
}

Me permite llamar: myEmployee.street-

1. Sólo sé Employee
2. Solo estoy acoplado Employee, no importa cuán compleja sea su estructura.

Menos conocimiento hasta el final

Nos desacoplado de myEmployee Persony Address, y lo ideal es que debemos seguir aplicando los conocimientos mediante la adición de por lo menos pase a través de las propiedades de tal manera que Employeesólo habla con Persony Personsólo habla conAddress

El estudio ( V. Basili, L. Briand y WL Melo. Una validación de las métricas de diseño orientado a objetos como indicadores de calidad ) ha demostrado que las clases con conjuntos de respuestas más grandes tienen tendencia a crear más errores que las clases con conjuntos de respuestas más pequeños porque hay más conjuntos de respuestas significa la posibilidad de un mayor acoplamiento.

El valor de la Ley de Demeter es que reduce la respuesta establecida por definición. El método de un objeto solo puede llamar a un método en sí mismo, a cualquier parámetro que se haya pasado al método, al método de cualquier objeto que haya creado y al método de cualquier objeto retenido directamente. Como el conjunto de respuestas es más pequeño, hay menos posibilidades de un alto acoplamiento. Dado que el módulo / método solo utiliza referencias inmediatas disponibles, existe una mayor cohesión.

Es bastante simple; digamos que A depende de B y B depende de C. Sin la Ley de Demeter puede usar tanto B como C en A pero al adherirse a esta ley, A depende solo de B, no puede depender de C.

Esto permite un bajo acoplamiento ya que reduce en gran medida el número de dependencias de un módulo; La cohesión, aunque es diferente en concepto del acoplamiento, se logra de la misma manera. Al tener menos dependencias en un módulo, estos se vuelven más específicos para ese módulo y, por lo tanto, aumentan la cohesión. Además, el número total de módulos aumentará y se volverán más especializados para hacer cosas especializadas para el módulo dependiente (contrario a los objetos divinos) que se traduce directamente en un sistema más coherente.