迪米特法则 —— 看似正确却潜藏错误认知
深入理解迪米特法则，避免错误应用
迪米特法则（Law of Demeter）是面向对象编程设计中的一项基本原则。它要求设计者将一个对象的正常操作的调用限制在最小范围内，即一个对象应该对其它对象尽可能少的了解，而被调用的对象也应当尽可能少地与调用者发生直接交互。尽管这是一个很好的编程实践，但在实际应用中，对于它被误解的情况，也需引起注意。
迪米特法则误解一：过度封装造成难以维护
过度封装将导致代码难以维护，是大部分开发人员理解为迪米特法则的误区，而迪米特法则只是要求最小限度地暴露对象的接口，不过度封装。
过度封装不仅显著增加程序员的工作负担，而且还会影响代码可读性和可维护性。设计类的时候应当权衡好两者之间的平衡关系，将对象的内部细节封装，同时为外部提供有用、可靠的接口。
迪米特法则误解二：随意增加代码的复杂性
在编程设计过程中，一种常见的误解是通过增加代码的复杂性来解决问题。根据迪米特法则，调用者应该只关心与被调用对象直接发生交互的结果，而忽略被调用对象内部的实现细节，这样可能会降低代码的复杂性。如果我们将对象的遍历方式暴露出来，这会增加代码的复杂性，因为新的实现方式会增加代码复杂性并对代码做出不必要的让步。
而应当采用的方案应当是，针对对象的内部细节，将其封装到对象的方法中，并在对象接口上提供最小化、清晰明了的方法调用，同时使得对象对其它的对象依赖最少。
迪米特法则误解三：忽视代码的复用性和可扩展性
一些开发人员可能会因为迪米特法则而放弃代码的复用性和可扩展性，认为代码库的复杂性会类似于代码库的维护难度。这显然是一种错误的想法，复杂的代码可以进行模块化设计，模块间设定好接口，从而提高代码的复用性和可扩展性。
在应用迪米特法则时，我们应当根据情况合理设计类之间的依赖关系，将复杂度分离在不同的模块之间，这样可以在不同的场景中提高代码的复用性和可扩展性，清晰地规划代码内部的依赖关系，使得整个设计更加强健、更加灵活。
