设计模式 – 单一责任和混合

发布时间：2020-12-13 20:47:09 所属栏目：百科来源：网络整理

导读：鉴于 Mixins通常会在类中引入新行为,这通常意味着类会有多个行为. 如果一个类只有一个责任,则将其定义为只有一个改变原因的类. 所以,我可以从两个不同的角度看待这一点班级只有一个改变的理由.混合的模块也只有一个变化的原因.如果更改了类,则只需要重新测

鉴于 Mixins通常会在类中引入新行为,这通常意味着类会有多个行为.

如果一个类只有一个责任,则将其定义为只有一个改变原因的类.

所以,我可以从两个不同的角度看待这一点

>班级只有一个改变的理由.混合的模块也只有一个变化的原因.如果更改了类,则只需要重新测试类.如果更改模块,则只需要重新测试模块.因此,SRP是完整的.
>班级现在有两个改变的原因.如果更改了类,则类和模块都需要重新测试.如果更改了模块,则类和模块都需要重新测试. Henge,SRP受到侵犯.

mixins的使用是否违反Single Responsibility Principle,最终导致系统难以维护？

当您需要在不相关的类之间共享行为时(有时您需要),基本上有三个选项：

>到处复制和粘贴.这违反了DRY,保证损害可维护性.
>将它放入一个抽象类中,让所有类(其中许多类彼此无关)继承它.这通常被认为是OO反模式.简单地说,它完全破坏了头部的继承概念.只是因为foo和bar做了同样的事情,你并不认为foo是一个酒吧.
>把它放在其他地方,给它一个明确的名字,并将它混合到所有需要它的类中.

至于测试,我认为一个“好”的mixin,就像一个好的常规方法,应该松散地耦合到它和使用它的类可以独立使用.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!