迪米特法则定义
erp解耦的设计原则？
erp解耦的设计原则？
erp解耦设计原则:
1.单一职责原则(变化分离)
应该有且只有引起它变化的原因.如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.
2.里氏替换原则(解释如何进行继承)
基类可以出现的地方都可以用子类进行替换,而不会引起任何不适应的问题.
里氏替换原则是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为.
里氏代换原则是对“开-闭”原则的补充.实现“开-闭”原则的关键步骤就是抽象化.
覆盖或实现父类的方法时,子类返回值类型可以是父类返回值类型的子类.
3.依赖倒置原则(针对接口编程)
高层模块不应该依赖于低层模块,他们都应该依赖于抽象；抽象不应该依赖于具体实现,具体实现应该依赖于抽象.
(低层模块,不可分隔的原子逻辑即为低层模块高层模块,原子逻辑的再组装形成高层模块)
针对接口编程,依赖于抽象而不依赖于具体.降低客户与实现模块间的耦合.
4.接口隔离原则(恰当的划分角色和接口)
客户端不应该依赖于它不需要的接口类间的依赖关系应该建立在最小的接口上.
因此,使用多个隔离接口比使用单个接口好.
一个接口代表一个角色,不应当将不同的角色都交给一个接口.
没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染.
不应该强迫客户依赖于它们不用的方法.
接口属于客户,不属于它所在的类层次结构.
5.迪米特法则(最小知道原则)
一个对象应该对其它对象有最小的了解.
一个软件实体应尽可能少的与其它实体发生相互作用,使得系统模块功能相对独立.
每一个软件单位对其它的单位都只有最少了解,而且局限于那些与本单位密切相关的软件单位.
类成员函数应该只调用以下对象:
对象自身,函数参数,成员对象,成员集合中的元素,函数中创建的对象.
6.开闭原则(可变性封装)
软件组成实体(类,模块,函数等)应该是可扩展的,但是是不可修改的.即软件实体可以通过增加新代码实现扩展,但是不能修改已有的代码.
任何系统在其生命周期中都会发生变化,如果我们希望开发出的系统不会在第一版发布后就被抛弃,就必须牢记这一点.
把会变化的部分抽取并封装起来,以便以后可以轻易地改动和扩充,而不影响不需要变化的其它部分。