设计原则-个人浅解

1 开闭原则: 一个软件实体[接口,类,方法,项目等]对修改关闭对扩展开放.

个人理解: 稳定的软件实体[接口,类,方法等]修改后可能就会导致其它的问题,比如之前功能受到影响,而且修改的时候可能还要关注之前已有的细节,增加维护成本.

在不修改原来的代码的基础上通过扩展来增加新的功能模块.降低了耦合性,也不用更多的关注之前功能的细节,降低风险.这可能需要我们在设计之初就要考虑到将公共的东西进行抽象,以便后面功能更容易拓展.

2 单一职责原则: 一个软件实体类,方法等, 只能有一个导致变更单原因.即软件实体功能职责单一,不要负责过多的功能

个人理解: 功能承载过多的话势必会导致内部逻辑非常复杂,耦合性高 ,当你想改动某一小点的时候就会影响到另外的一个或者多个功能,非常难以维护.

之前重构一个接口的代码的时候就是因为那个接口有过多的职责,导致业务层和查询SQL异常的复杂,并且性能很低. 后面实在是在原有基础上改不了,然后我将这个接口拆分成了几个小的接口.性能和代码都简洁度都提高了很多.

如果出现多于一个维度场景导致实体变更可能就要考虑抽象出来进行拆分了. 这样功能更加独立维护成本也会降低,相对也提供了更多另活的组合方式. (分布式架构中业务的拆分应该也是有类似的思想)

3 依赖倒置原则: 高层不应该依赖于低层细节,两者都应该依赖于抽象.

个人理解: 应用层不应该依赖于具体的实现,应该依赖于基于实现的抽象. 而实现层也是不应该依赖于某一个具体的应用,也是应该依赖于基于应用层的抽象.

例如 就像客户去银行办理业务而不是每次去找某一个特定的业务员去办理业务,如果这个特定的营业员今天有事怎么办. 同样银行的业务员也不可能只给某一个指定的客户去办理业务.

客户就是高层的应用层,而银行则是抽象 ,业务员是具体的抽象实现者. 一句话来说面向抽象编程因为抽象的东西更加的稳定.而且能够使耦合度降低.后期也会容易维护和扩展.

4 接口隔离原则 :客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小的接口上.

个人理解: 不要把很多的非公共方法塞进一个接口,这样会导致接口很臃肿,应该根据实际的需要细化接口. 否则则会造成类的污染.即提供了客户端不需要的功能显得很鸡肋.如果后续使用了这个冗余功能也会出现问题,灵活度也会降低. 其实就是说我不需要的东西别给我.

5 迪米特法则: 一个类应该和它的朋友(入参,出参,属性)进行通信,不和陌生人进行通信.

个人理解: 类与类之间相互知道的越少越好,如果A软件实体和B软件实体关系很密切,则当A软件实体变动的时候对B的影响就会很大, 其实就是使得各个模块之间相互知道的越少越好,这样耦合度才会更低,也会更加灵活,复用性更高.

6 里氏替换原则: 在所有使用父类的地方都能够透明的使用其子类.

个人理解: 避免继承后子类改变了其原有的功能所带来的风险. 就像软件升级后也会兼容其原有的功能.我们之前使用父类的功能,也有可能后面用子类替换,或者我们使用多态的时候.要保证功能一致.

如果子类的部分功能发生了变化 , 并且子类对某些功能进行了优化. 那么我们现在想使用这个优化需要替换成当前这个子类那么如果用到了它改变的功能则会发生问题.

7 合成.组合原则: 依赖于其它的类的时候,用组合或者聚合来替换继承.

个人理解: 继承耦合度过高,能够获取到父类所有的细节.如果父类发生了变化,则子类的功能也会相继的变化.如果继承系统非常大则会非常难以维护,系统风险也比较高. 如果使用较为弱的依赖关系则能大大的降低耦合度,降低系统的风险,和后期的维护成本,灵活度也比较高.

总结:

这些原则其实也是前人踩过很多的坑,所总结出来的经验. 如果我们设计的时候能够适当遵循这些原则能帮我跳过很多的问题.提供系统的稳定性,方便后期的维护和扩展.当然这些原则要根据自己的使用场景来考虑怎么使用,并不一定要只套原则. 这些原则只是口诀,心法.具体的招式要你自己去考虑.而且这些东西本身就很抽象,并非一朝一夕的就能领会到所有,还是要结合具体的经验,场景领悟的东西才会越来越多. 由于我自己经验也比较浅薄有很多东西也无法理解的清楚,可能有些地方也理解的不太对,如果有什么错误的地方或者有其它更好的理解都可以指出.谢谢.