单一职责原则

单一职责原则

单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因
比如我们写一个窗体应用程序，一般都会生成一个Form1这样的类，于是我们就把各种各样的代码，像某种商业运算的算法呀，像数据库访问的SQL语句呀神那么的都写到这样的类当中，这就意味着，无论任何需求要来，你都需要更改这个窗体类，这其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或则抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
所以，**软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，**就应该考虑类的职责分离。

开放-封闭原则

开放-封闭原则（OCP）：是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改
现实中的一国两制就是开放、封闭原则的一种体现。对于扩展是开放的，对于更改是封闭的。
我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会发生变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。怎样的设计才能面对需求的改变却可以相对稳定给，从而使得系统可以在第一个版本以后不断退出新的版本呢？
绝对的对修改关闭是不可能的。无论模块是多么的”封闭“，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。
猜测程序可能会发生的变化，猜对了，那是成功，猜错了，那就完全走到另一面去了，把本该简单的设计做的非常复杂，很不划算，而且事先猜测，这又是很难做到的。所以，我们可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动。
最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化，比如之前编写的加法程序，就分离出了抽象的运算类，这样，如果新增计算方法，也只需要增加新的类，而不用去修改已经存在的类。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可拓展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意的进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

依赖倒转原则

针对接口编程，不要对实现编程

1. 高层模块不应该依赖低层模块。两个都应该依赖抽象。
2. 抽象不应该依赖细节。细节应该依赖抽象。

##里氏代换原则
**一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的字节，程序行为没有变化，**简单地说，子类型必须能够替换掉它们的父类型。
举个例子，在面向对象设计时，一个是鸟类，一个是企鹅类，如果鸟是可以飞的，企鹅不会飞，那么企鹅是鸟吗？企鹅可以继承鸟这个类吗？
在面向对象设计时，子类拥有父类所有非private的行为和属性。鸟会飞，而企鹅不会飞。尽管在生物学分类上，企鹅是一种鸟，但在编程世界里，企鹅不能以父类–鸟的身份出现，因为前提说所有鸟都能非，而企鹅飞不了，所以，企鹅不能继承鸟类。
也正因为有了这个原则，使得继承复用成为了可能，**只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。**比如说，猫是继承动物类，以动物的身份拥有吃、喝、跑、叫等行为，可当某一天，我们需要狗、牛、羊也拥有类型的行为，由于它们都是继承于动物，所以除了更改实例化的地方，程序其他处不需要改变。
依赖倒装其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或接口，那就是面向对象的设计，反之那就是过程化的设计。

装饰模式

举个例子，以策略模式为例子

#抽象类--装饰
#include 
using namespace std;
class Finery
{
public:
	virtual void show() {};
};

#T恤
#include "Finery.h"
class TShirts :
    public Finery
{
public:
    void show() 
    {
        cout << "大T恤" << endl;
    }
};

#裤子
#include "Finery.h"
class BigTrouser :
    public Finery
{
public:
    void show()
    {
        cout << "垮裤" << endl;
    }
};

#人
class Person 
{
private:
	string name;

public:
	Person(string name)
	{
		this->name = name;
	}

	void Show()
	{
		cout << "装扮的 " << name << endl;
	}
};

#main
    Person *xc = new Person("xc");
	Finery *dtx = new TShirts();
	Finery* kk = new BigTrouser();
	dtx->show();
	kk->show();
	xc->Show();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

这样写就相当于当着大家的面，先穿T恤，再穿裤子，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

#抽象类 Component
#include 
using namespace std;
class Component
{
public:
	virtual void Operation() = 0;
};

#具体对象
#include "Component.h"
class ConcreteComponent :
    public Component
{
public:
    void Operation()
    {
        cout << "具体对象的操作 " << endl;
    }
};

#装饰类
#include "Component.h"
class Decorator :
    public Component
{
protected:
    Component *component;

public:
    void SetComponent(Component *component)
    {
        this->component = component;
    }

    void Operation()
    {
        if (component != nullptr)
        {
            component->Operation();
        }
    }
};

#装饰对象A
#include "Decorator.h"
class ConcreteComponentA :
    public Decorator
{
private:
    string addedState;

public:
    void Operation()
    {
        Decorator::Operation();
        addedState = "New State";
        cout << "具体装饰对象A的操作" << endl;
    }
};

#装饰对象B
class ConcreteComponentB :
    public Decorator
{
private:
    void AddedBehavior()
    {
        cout << "ConcreteComponentB 独有的操作" << endl;
    }

public:
    void Operation()
    {
        Decorator::Operation();
        AddedBehavior();
        cout << "具体装饰对象B的操作" << endl;
    }
};

#使用
    ConcreteComponent* c = new ConcreteComponent();
	ConcreteComponentA* d1 = new ConcreteComponentA();
	ConcreteComponentB* d2 = new ConcreteComponentB();
	d1->SetComponent(c);
	d2->SetComponent(d1);
	d2->Operation();
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

装饰的方法是：首先用ConcreteComponent实例化对象c，然后用ConcreteComponentA的实例化对象d1来包装c，再用ConcreteComponentB的对象d2包装d1，最终执行d2的Operation()
装饰模式是利用SetComponent来对对象进行包装的。这样每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。
装饰模式是为已有功能动态地添加更多功能的一种方式。当系统需要更新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为，在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式却提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因为，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。
装饰模式的顺序是非常、非常、非常重要的