Definição: Um objeto deve saber menos sobre outros objetos
O conceito central da lei de Dimitri está dissociando entre classes e acoplamento fraco. Somente após o acoplamento fraco a reutilização das classes pode ser melhorada.
Uma metáfora mais vívida é semelhante a: prisioneiros na prisão não devem entrar em contato com pessoas do lado de fora, é claro que pode haver parentes visitantes. A prisão aqui é a classe, os prisioneiros internos são as informações dentro da classe, e os guardas da prisão na prisão são equivalentes ao executor da Lei Dimit.
As reivindicações da lei de Dimit:
(1) em termos de divisão de classe, as classes com acoplamento fraco devem ser criadas;
(2) No design da estrutura da classe, cada classe deve minimizar os direitos de acesso dos membros;
(3) No design de uma classe, se possível, uma classe deve ser projetada como uma classe inalterada;
(4) em termos de referências a outras classes, as referências de um objeto para outros objetos devem ser minimizadas;
(5) tente minimizar os direitos de acesso à classe;
(6) use a função de serialização com cautela;
(7) Não exponha membros da classe, mas forneça o acessador correspondente (propriedades).
Para dar um exemplo: existe uma empresa de grupo e as unidades subordinadas têm filiais e departamentos diretos. Agora é necessário imprimir os IDs dos funcionários de todas as unidades subordinadas. Vamos primeiro olhar para o design que viola a regra Dimit.
// Chefe do funcionário da classe da sede {private String ID; public void setId (string id) {this.id = id; } public string getId () {return id; }} // Classe do funcionário da filial Subemployee {private String ID; public void setId (string id) {this.id = id; } public string getId () {return id; }} classe SubcompanyManager {public list <Subemployee> getAllEmployee () {list <SubemPleee> list = new ArrayList <Subemployee> (); for (int i = 0; i <100; i ++) {subemployee emp = new Subemployee (); // Atribua um ID ao pessoal da ramificação em ordem emp.setId ("ramil"+i); list.add (EMP); } Lista de retorno; }} classe CompanyManager {public list <clarey> getallemployee () {list <comester> list = new ArrayList <Eclarey> (); for (int i = 0; i <30; i ++) {funcionário emp = new funcionário (); // Atribua um ID ao pessoal da sede para o EMP.SETID ("Companhia Chefe"+I); list.add (EMP); } Lista de retorno; } public void PrintalLemployee (subcompanyManager sub) {list <Subemployee> list1 = sub.getallemployee (); para (subemployee e: list1) {System.out.println (e.getId ()); } List <cleame> list2 = this.getAllEmployee (); para (funcionário e: list2) {System.out.println (e.getId ()); }}} public class Client {public static void main (string [] args) {CompanyManager e = new CompanyManager (); E.PrintAlLEmployee (new SubcompanyManager ()); }} O principal problema desse design está agora no CompanyManager. De acordo com a lei de Dimit, apenas a comunicação com amigos diretos ocorre, e a classe subemployeada não é um amigo direto da classe da empresa (o acoplamento que aparece como variáveis locais não pertence a amigos diretos). Logicamente falando, a sede só precisa ser acoplada à sua filial e não tem conexão com os funcionários da filial. Esse design obviamente adiciona acoplamento desnecessário. De acordo com a lei de Dimit, esse acoplamento de relacionamento com amigos indiretos deve ser evitado na classe. O código modificado é o seguinte:
classe SubcompanyManager {list public <SubemPleee> getAllEmployee () {list <Subemployee> list = new ArrayList <Subemployee> (); for (int i = 0; i <100; i ++) {subemployee emp = new Subemployee (); // Atribua um ID ao pessoal da ramificação em ordem emp.setId ("ramil"+i); list.add (EMP); } Lista de retorno; } public void printemployee () {list <Subemployee> list = this.getAllEmployee (); para (subemployee e: list) {System.out.println (e.getId ()); }}} classe CompanyManager {public list <cleomem> getalleMPlanee () {list <cleame> list = new ArrayList <Eclarey> (); for (int i = 0; i <30; i ++) {funcionário emp = new funcionário (); // Atribua um ID ao pessoal da sede para o EMP.SETID ("Companhia Chefe"+I); list.add (EMP); } Lista de retorno; } public void PrintalLemployee (subcompanyManager sub) {sub.printeMployee (); LIST <EGARY> LIST2 = this.getAllEmployee (); para (funcionário e: list2) {System.out.println (e.getId ()); }}} Após a modificação, o método de impressão do ID do pessoal foi adicionado à filial e a sede diretamente a chamou para imprimir, evitando assim o acoplamento com os funcionários da filial.
A intenção original da Lei de Dimitter é reduzir o acoplamento entre as classes. Como cada classe reduz dependências desnecessárias, é realmente possível reduzir os relacionamentos de acoplamento. Mas tudo tem seus próprios padrões. Embora possa evitar a comunicação com os tipos indiretos, a fim de se comunicar, você inevitavelmente entrará em contato com a filial por meio de um "intermediário". Por exemplo, neste caso, a sede entra em contato com os funcionários da filial através da filial como o "intermediário". O uso excessivo do princípio Dimit resultará em um grande número dessas classes intermediárias e de transmissão, resultando em maior complexidade do sistema. Portanto, ao adotar a lei Dimitr, devemos pesar repetidamente as compensações, o que não apenas garante uma estrutura clara, mas também requer alta coesão e baixo acoplamento.