Definición: un objeto debe saber lo menos sobre otros objetos
El concepto central de la ley de Dimitri es el desacoplamiento entre clases y el acoplamiento débil. Solo después de un acoplamiento débil se puede mejorar la reutilización de las clases.
Una metáfora más vívida es similar a: los prisioneros en prisión no deben contactar a las personas afuera, por supuesto, puede haber parientes visitantes. La prisión aquí es la clase, los prisioneros dentro son la información dentro de la clase, y los guardias de la prisión en la prisión son equivalentes al ejecutor de la ley DIMIT.
La ley de Dimit afirma:
(1) En términos de división de clase, se deben crear clases con acoplamiento débil;
(2) En el diseño de la estructura de la clase, cada clase debe minimizar los derechos de acceso de los miembros;
(3) En el diseño de una clase, si es posible, una clase debe diseñarse como una clase sin cambios;
(4) En términos de referencias a otras clases, las referencias de un objeto a otros objetos deben minimizarse;
(5) Intente minimizar los derechos de acceso a la clase;
(6) Use la función de serialización con precaución;
(7) No exponga a los miembros de la clase, pero proporcione el accesor (propiedades) correspondiente.
Para dar un ejemplo: hay una empresa grupal, y las unidades subordinadas tienen sucursales y departamentos directos. Ahora se requiere imprimir las ID de empleados de todas las unidades subordinadas. Primero veamos el diseño que viola la regla Dimit.
// Jefe del empleado de la clase de oficina central {ID de cadena privada; public void setid (ID de cadena) {this.id = id; } public String getId () {return id; }} // SURSE DE SUBEMPLEADO DE LA CLASE DE EMPLEADO {ID de cadena privada; public void setid (ID de cadena) {this.id = id; } public String getId () {return id; }} clase SubCompanyManager {Public List <SubeMloyee> getAllEmloyee () {list <SubeMloyee> list = new ArrayList <SubeMloyeee> (); for (int i = 0; i <100; i ++) {subemployee emp = new SubEmployee (); // Asignar una ID al personal de ramificación en orden EMP.SetId ("Branch"+I); list.add (emp); } Lista de retorno; }} class CompanyManager {Public List <Elp.) GetAllEmployee () {List <Elpagey> list = new ArrayList <ElsperseeS> (); para (int i = 0; i <30; i ++) {Employee Emp = New Employee (); // asigna una ID al personal de la oficina central en orden EMP.SetId ("principal empresa"+i); list.add (emp); } Lista de retorno; } public void PrintAllEmployee (SubCompanyManager Sub) {list <SubeMloyee> list1 = sub.getAllEmloyee (); for (subemployee e: list1) {system.out.println (e.getID ()); } List <Els. Employee> list2 = this.getAllEmployee (); para (Empleado E: List2) {System.out.println (E.GetId ()); }}} Public Class Client {public static void main (String [] args) {CompanyManager e = new CompanyManager (); E.PrintLeMployee (nuevo SubCompanyManager ()); }} El principal problema de este diseño ahora está en CompanyManager. Según la ley de Dimit, solo se produce la comunicación con amigos directos, y la clase subempleada no es un amigo directo de la clase CompanyManager (el acoplamiento que aparece como variables locales no pertenece a amigos directos). Hablando lógicamente, la oficina central solo necesita ser combinada con su sucursal y no tiene conexión con los empleados de la sucursal. Este diseño obviamente agrega un acoplamiento innecesario. Según la ley de Dimit, se debe evitar tal acoplamiento de relación de amigos indirectos en la clase. El código modificado es el siguiente:
clase SubCompanyManager {Public List <SubEmployee> getAllEmloyee () {list <SubEmployee> list = new ArrayList <SubeMloyeee> (); for (int i = 0; i <100; i ++) {subemployee emp = new SubEmployee (); // Asignar una ID al personal de ramificación en orden EMP.SetId ("Branch"+I); list.add (emp); } Lista de retorno; } public void printEmployee () {list <SubeMloyee> list = this.getAllEmployee (); for (subemployee e: list) {system.out.println (e.getID ()); }}} class CompanyManager {Public List <EplayeeS> getAllEmployee () {List <Elpagey> list = new ArrayList <ElsperseeS> (); para (int i = 0; i <30; i ++) {Employee Emp = New Employee (); // asigna una ID al personal de la oficina central en orden EMP.SetId ("principal empresa"+i); list.add (emp); } Lista de retorno; } public void PrintallEmployee (SubCompanyManager Sub) {sub.printemloyee (); List <Elp. Employee> list2 = this.getAllEmployee (); para (Empleado E: List2) {System.out.println (E.GetId ()); }}} Después de la modificación, el método de imprimir la ID de personal se agregó a la sucursal, y la oficina central lo llamó directamente imprimir, evitando así el acoplamiento con los empleados de la sucursal.
La intención original de la ley del dimitador es reducir el acoplamiento entre las clases. Dado que cada clase reduce las dependencias innecesarias, de hecho es posible reducir las relaciones de acoplamiento. Pero todo tiene sus propios estándares. Aunque puede evitar la comunicación con tipos indirectos, para comunicarse, inevitablemente se comunicará con la rama a través de un "intermediario". Por ejemplo, en este caso, la oficina central contacta a los empleados de la sucursal a través de la sucursal como el "intermediario". El uso excesivo del principio DIMIT dará como resultado una gran cantidad de tales clases de intermediarios y de transmisión, lo que resultará en una mayor complejidad del sistema. Por lo tanto, al adoptar la ley de Dimitr, debemos sopesar repetidamente las compensaciones, lo que no solo garantiza una estructura clara, sino que también requiere una alta cohesión y un bajo acoplamiento.