设计模式一:面向对象的几个设计原则

2017-10-03 20:45:49

单一职能原则:

在设计一个类的时候，要保证它的职责（也就是这个类做的事情）尽量单一，不要把不相关的功能都写在一个类中，也就是要明确划分每个类的作用，职责是什么，目的是实现类与类之间的解耦，并且有利于 代码的复用！

开闭原则：
一个软件实体应该对修改关闭，对扩展开放！ 
对修改关闭:目的是为了修改带来的对以前软件的破坏，甚至不能运行，比如在设计一个类时有一个用来初始化的方法，并且创建该对象必须调用该方法，我们希望这个方法不能被修改，任何继承这个类的对象都不能随意修改重写这个方法，否者可能造成错误，我们可以用final修饰该方法，并且如果这个方法也不想对外透明，可以用private修饰
对扩展开放：扩展是大多数软件都需要的！由于需求的变更可能就会对软件进行变更，要做到扩展就要抽象，比如面向接口编程，设计继承体系，以后的扩展就是编写不同的实现类，但是该类继承类，或者实现接口、在使用对象的地方用父类来做为类型，又比如做配置文件，只需要该写配置文件就能切换到不同的实现类

里氏代换原则：所有引用基类的地方必须能够引用子类的对象，也就是面向接口编程
或者设计继承体系

依赖倒转：
针对接口编程，而不针对实现编程！

要抽象出顶层的基类，而不是直接编写实现类，为了达到扩展性，函数传参的类型，要声明为父类，在编写实现类是需要依赖哪些对象时，通过注入（getter setter 构造函数）

接口隔离原则：

这个和单一职责有点类似，不要把所有方法都声明在一个接口中，划分他们的职能，分离接口，我们需要什么功能就实现什么功能，而没有必要实现不相关的方法，当然要做到适可而止，不能造成接口泛滥，复杂

合成复用原则：尽量使用对象组合来达到复用的目的，而不是继承！

    继承会带来不灵活性，并且提高了耦合度，比如有一个类Car，有一个类 Drive，Car类要想开动车需要调用一个drive方法，但是我们能继承吗？这个 两个类根本没多大关系，而且带来了不灵活性，如果继承，不重写要想开车就 只能调用Drive的dirve方法，如果直接把申明一个Drive对象作为属性，那么 就可以自由组合怎么开车。继承带来了的高耦合问题，如果重写了一个Drive 的方法，并且你加上了@Override注解，要是Drive的那个方法被删除了，你的 子类就会报错了，如果只是作为属性对象就不会有这个问题，因为该对象对 Car是不可见的

迪米特法则：一个软件实体应该尽可能少于其他软件实体发生相互作用，
也就是尽可能的解耦，以防修改带来的影响