模式访客违反得墨忒耳的法律？

Question

Demeter法则期望在类之间进行最松散的耦合.

这意味着在类中暴露的所有getter/setter中有90%必须被"删除"并替换为"包含行为"的方法.实际上,它对应于"告诉,不要问"的哲学,因为不希望客户通过糟糕的getter/setter方法来帮助处理行为本身.如果在其他地方使用相同的操作,这也会减少重复的代码.

如果我们想要尊重单一责任原则,这意味着有许多行为方法的大型课程和过度使用授权.

另一方面,访问者模式定义是:

访问者允许您定义新操作,而无需更改其操作的元素的类.

所以,乍一看,似乎与德米特法律的期望相反:

• One(Visitor)意味着类结构提供getter/setter,以便Visitor可以修改对象的状态而不需要触及类本身.

• 其他(Demeter)鼓励将与对象直接相关的所有行为代码包含在同一个类中.

所以我的问题是:

我们何时可以考虑关闭一个类进行修改,从而停止在其上添加行为方法,因此更喜欢将它们添加到新创建的访问者中,客户端使用getter/setter而不是在初始类之前已经暴露的行为方法的风险很大？

Answer 1

简短的回答是否定的.

首先,我不认为"告诉,不要问"说你应该删除所有的getter和setter,但如果他们没有添加任何值或暴露内部状态,你应该删除它们.因此,作为一个例子,getter应尽可能多地尝试返回不可变数据.setter的示例是adjusment或policy对象,这些对象是实例无法正常工作所需的对象,但如果提供,则会更改行为.

其次,我从未见过访客模式的描述,暗示被访问对象应该有getter和setter,因此访问者可以修改它们.与任何其他对象一样,我们的想法是使用被访问对象公共API来进行任何扩展.另外暗示肯定也不利于封装.

关于另一个主题,我对你的最后一段感到有点困惑,因为我不知道你是在谈论开放/封闭原则,还是关于如何使用访客模式构建一个功能.

需要注意的是,我认为关键是要了解SOLID,Demeter法和所有其他做法都是良好做法而不是最佳做法("最佳做法"是一个营销术语).如果你采取任何这些做法到极端,它们可能最终会损害代码的可读性或可维护性.

(顺便问一下,好问题:D)

开放/封闭原则的好处主要适用于其他人将以我们无法预料的方式使用的代码(框架就是这样的一个例子).因此,如果您正在编写框架,则需要添加扩展点并使用语言功能来防止继承类(例如java中的final或密封在C#中)或者只是让开发人员覆盖某些方法.这个想法是为了防止一个天真的用户覆盖一个重要的对象并使框架以意想不到的方式中断.一些语言/框架嘲笑这一点(例如Ruby/Rails),它们鼓励用户打开类来添加或修改功能(取得了相当大的成功).

如果你正在编写一个应用程序(并且你拥有代码),我建议你不要过分关注开放/封闭原则,并专注于应用得墨忒耳定律(理解程度:D).