该得墨忒耳定律指出你应该只给你关于直接了解对象说话.也就是说,不要执行方法链接与其他对象交谈.当您这样做时,您正在与中间对象建立不正确的链接,不恰当地将您的代码与其他代码耦合.
那很糟.
解决方案是针对您所知道的类,基本上公开简单的包装器,将责任委托给与其有关系的对象.
非常好.
但是,这似乎导致班级具有低凝聚力.它不再只是简单地对其所做的事情负责,但它也有代表在某种意义上,通过复制其相关对象的部分界面使代码更具凝聚力.
那很糟.
它真的会降低凝聚力吗？它是两个邪恶中的较小者吗？
这是发展的灰色区域之一,您可以在哪里讨论线路的位置,或者是否有强有力的,有原则的方式来决定在哪里划线,以及您可以使用哪些标准来做出决定？