本文探讨了设计模式的核心概念及六大设计原则：单一职责原则、里氏替换原则、依赖倒转原则、接口隔离原则、迪米特法则及开放-封闭原则。详细解释了每个原则的含义、应用实例及注意事项，旨在帮助开发者构建更加灵活、可维护的软件系统。
刚刚结束设计模式学习时，感觉哪哪的抓不住重点，虽然之前师傅给勾了写比较重要的设计模式，但是给我的感觉设计模式怎么全都一个样子。
通过对一些文章的浏览，简单的对设计原则总结了一下。
设计模式，就是设计范例。
是经典问题的解决方案，是可以让学习者举一反三的，有研究价值、有交流价值的例子。
具体而言，是封装、继承、多态和关联的反复使用。其中核心是封装的概念。
设计模式还是很重要的，但是在这里我不想多提，对于设计模式学习，我也只是刚刚开始，对于每个设计模式掌握的也并不是很好，只能照本宣科，并不能有什么自己的东西。
下面简单说一下设计模式的六大设计原则
（以下排名不分先后 ^O^ ）
单一职责原则
问题出现：一个类负责多个事务，当有一个事务有变动时，可能会影响其他事务不能正常执行。
解决方法：由此就有了单一职责原则，一个类只干一件事。
乍一听还是非常简单的，但是因为职责扩撒的存在，有些时候并不能很好的遵循。
什么是职责扩散，就是因为某些原因一个职责被细分为两个或多个职责。
关于职责扩散，我借鉴的文章种有个例子，但是并不是太好，所以并没有拿过来。
对于原则的使用还是有个度，对于这个度的还是要自己把控，只要逻辑的复杂度自己能够把控就好了。
优点：
1.可以降低类的复杂度，一个类只负责一个职责，其逻辑肯定比负责多项职责简单的多
2.提高类的可读性，提高系统的可维护性
3.变更引起的风险降低
里氏替换原则
这一原则我还是似懂非懂，即使看了多篇文章，但是用字遣词都不太理解，耐人寻味，最后我只能留下他们，等待后续的解答
里氏替换原则的4层含义：
1.子类可以实现父类的抽象方法，但不能覆盖父类的抽象方法。
2.子类可以增加自己特有的方法
3.当子类的方法重载父类的方法时，方法的前置条件（方法的形参）要比父类方法的输入参数更宽松
4.当子类的方法实现父类的抽象方法时，方法的后置条件（方法的返回值）要比父类更严格
依赖倒转原则
高层模块不应该依赖底层模块，二者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
看了些资料，例子或者定义也写了一大堆，最容易让我理解的还是《大话》中写到的，内存条CUP都不应该依赖于主板，都应依赖于接口这个抽象。
在实际编程中应做到：
1.底层模块尽量都要有抽象类或者接口，或者两者都有。
2.变量的生命类型尽量是抽象类或接口。
3.使用继承时遵循里氏替换原则。
依赖倒转原则的核心就是我们面向接口编程。
接口隔离原则
客户端不应该依赖他不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。
简单的理解，就是一个类通过一个接口来实现另一个类，但是接口中有一些方法是不需要的，这不是画蛇添足么。
下面看两个图片不用多说什么就了解了
在使用接口隔离原则时应注意：
1.接口尽量小，但要有限度。对接口进行细化可以提高程序灵活性，但是事如果过小，则会造成接口数量过多，是设计复杂化。
2.为依赖接口的类定制服务，只暴露给调用它的类所需要的方法，不需要的方法则隐藏起来。只有专注的为一个模块提供定制服务，才能建立最小的依赖关系。
3.提高内聚，减少对外交互。使用接口最少的方法完成最多的事情。
迪米特法则
一个对象应该对其他对象保持最少的了解。
迪米特法则的根本思想就是强调类之间的松耦合。
看过了《大话》也读了例子，还是不能像上面的原则一样，说在使用时应注意些什么，我只能说，注意类之间的松耦合。
开放-封闭原则
软件实体（类、模块、函数等）应该可扩展，但是不可修改。
刚开始我还不是很能理解的，直到我看到了：对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
总结
最后说一下如何遵守六个原则。对于这六个原则遵守时不是是和否的问题，而是多和少的关系。就是平时我们说的时候不会说，有没有遵循，而是说 遵循的程度。
下面我们看两幅图
图中的每一条纬度代表一项原则，我们依据对这项原则的遵守在纬度上面画一个点，则如果对这项原则遵守的合理的话，这个点应该落在红色的同心圆内部；如果遵守的差，点将会在小圆内部；如果遵循过度，点将会落在大圆外部。一个良好的设计体现在途中，应该是六个顶点都在同心圆中的六边形。
在上图中，设计1、 2属于良好的设计，设计3、 4虽然有些不足，但也基本可以接受，设计5、 6则严重不足。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
