本教程将通过 java 实例，一步一步向您讲解设计模式的概念。
1.单一职责原则(single responsibility principle)目的：降低代码复杂度、系统解耦合、提高可读性
含义：对于一个类，只有一个引起该类变化的原因；该类的职责是唯一的，且这个职责是唯一引起其他类变化的原因。
解决：将不同的职责封装到不同的类或者模块中。 当有新的需求将现有的职责分为颗粒度更小的职责的时候，应该及时对现有代码进行重构。当系统逻辑足够简单，方法足够少，子类够少或后续关联够少时，也可以不必严格遵循你srp原则，避免过度设计、颗粒化过于严重。
实例：电线类wire为居民供电，电压为220v；但是新的需求增加，电线也输送高压电，电压为200kv，原有电线类可以增加方法实现扩充，这就违背了单一职责原则。可以提供基类，创建两个派生类，居民供电线、高压输电线。
2.里氏代换原则（liskov substitution principle）目的：避免系统继承体系被破坏
含义：所有引用基类的地方必须能透明地使用其子类的对象。
解决：子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法；子类中可以增加自己特有的方法；当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。如果子类不能完整地实现父类的方法，或者父类的一些方法在子类中已经发生畸变，则建议断开继承关系，采用依赖，聚合，组合等关系代替继承。
实例：已经定义鸟类具有两个翅膀飞的方法；新加入鸵鸟，不会飞，如果覆盖父类的方法，在两个翅膀飞的方法中什么也不做，就违背里氏替换原则，导致所有鸟都不会飞。应该创建并列的两种鸟基类，会飞与不会飞的。前置条件更宽松、后置条件更严格，比如父类返回map，子类返回hashmap；父类接受hashmap形参，子类接受map。
3.依赖倒转原则（dependence inversion principle）目的：避免需求变化导致过多的维护工作
含义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
解决：面向接口编程，使用接口或者抽象类制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
实例：母亲类mother有讲故事方法tellstory，依赖一个book类输入，并使用了book类的getcontent方法以便讲故事。那么下次需要母亲讲报纸上的故事、手机上的故事时，原有接口无能为力。这时，抽象一个包含getcontent方法的ireader基类，book、newspaper、cellphone各自实现。母亲的tellstory方法接受一个ireader实例，并调用getcontent方法即可。
4.接口隔离原则（interface segregation principle）目的：避免接口过于臃肿
含义：客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。
解决：适度细化接口，将臃肿的接口拆分为独立的几个接口。
实例：考试接口，包含考语数外、理化生、政史地等方法。学生类，实现考试接口，参加考试。文科生类、理科生类派生自学生类，实现考试接口时，就都需要实现一些自己不需要的方法（因为文科生不考理化生、理科生不考政史地）。这时，需要对考试接口进行细化，分为基础科考试接口、文科考试接口和理科考试接口；学生类实现基础科考试接口；文科生、理科生另外各自实现文科考试接口、理科考试接口。
5.迪米特法则（demeter principle）目的：降低类与类之间的耦合
含义：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
解决：不发生依赖、关联、组合、聚合等耦合关系的陌生类不要作为局部变量的形式出现在类的内部。
实例：校长管理老师，老师管理学生。校长需要全体点名时，首先对老师点名，但是不必通过老师获取学生的信息并点名，而应该让老师对各自管理学生的点名，否则校长和学生之间就发生了原本不必要的耦合，这样当学生类发生变化时，既要修改老师类，也要修改校长类。
6.合成复用原则（composite reuse principle）目的：防止类的体系庞大
含义：当要扩展类的功能时，优先考虑使用合成/聚合，而不是继承。
解决：当类与类之间的关系是is-a时，用继承；当类与类之间的关系是has-a时，用组合。
实例：如桥接模式，抽象和实现可以独立的变化，扩展功能时，增加实现类即可；比如装饰模式，只需要一个类，即可为一类类扩展新功能。对于显示图形需求，用图形shape类，和显示paint类实现。每个shape类有一个paint类指针负责图形绘制显示。paint类派生redpaint类和bluepaint类，传递给shape类，实现图形不同颜色绘制，这样图形绘制逻辑和图形绘制实现可独立变化。某天增加需求，所有的绘制需要加边框，可增加paintdecorator类，派生自paint基类，每一个paintdecorator类有一个paint对象指针，增加虚函数addedpaint，重写paint的绘制方法，增加addedpaint方法的调用。增加borderpaintdecorator类，派生自paintdecorator类，重写addedpaint方法，增加添加绘制边框代码。这样新增加一个类可以对原始所有画笔类的功能进行扩充。
7.开闭原则（open close principle）目的：提高扩展性、便于维护
含义：对扩展开放，对修改封闭。即系统进行扩展是被鼓励的，对现有系统代码进行修改是不被支持的。也就是说，当软件有新的需求变化的时候，只需要通过对软件框架进行扩展来适应新的需求，而不是对框架内部的代码进行修改。
解决：设计模式前面6大原则以及23种设计模式遵循的好，开闭原则自然遵守的好。对需求的变更保持前瞻性和预见性，就可以使抽象具有更广泛适用性，设计出的软件架构就能相对稳定。软件需求中易变的细节，通过从抽象派生出实现类来扩展。
附：合成复用原则的实例代码，组合使用桥接模式和装饰模式#include <iostream>//绘制类class paint{public: virtual void draw() = 0;};//红色绘制类class redpaint : public paint{public: void draw() { std::cout << "color red!" << std::endl; }};//蓝色绘制类class bluepaint : public paint{public: void draw() { std::cout << "color blue!" << std::endl; }};//图形类，使用桥接模式，将图形绘制逻辑与绘制实现解耦class shape{public: shape(paint* pt) : m_ppt(pt) { } virtual void show() { std::cout << "shape style:" << std::endl; m_ppt->draw(); }protected: paint* m_ppt;};//长方形类class rectangle : public shape{public: rectangle(paint* pt) : shape(pt) { }};//圆形类class circle : public shape{public: circle(paint* pt) : shape(pt) { }};//附加绘制类，使用装饰模式，对原有绘制类进行功能扩展class paintdecorator : public paint{public: paintdecorator(paint* pt) : m_ppt(pt) { } void draw() { m_ppt->draw(); addedpaint(); } virtual void addedpaint() = 0;protected: paint* m_ppt;};//附加边框类，对绘制类添加边框绘制功能class boarderdecorator : public paintdecorator{public: boarderdecorator(paint* pt) : paintdecorator(pt) { } void addedpaint() { std::cout << "with boarder!" << std::endl; }};void main(){ shape* pshape = new circle(new boarderdecorator(new redpaint())); pshape->show(); return;}
相关推荐：
javascript设计模式之工厂模式和构造器模式_javascript技巧
javascript设计模式初探_javascript技巧
以上就是设计模式七大原则总结的详细内容。