设计模式---六大原则 ---cookie

先说一下对面向对象的理解，万事万物皆对象。下面简单说一下几种关系在面向对象编程时的实现方式。

场景一：

师傅----》徒弟关系 ： 徒弟学会了师傅的技能 ，然后在此基础上又学会了其他的技能； 也就是对程序的分层拓展；

在面向对象中就可以用 子类继承父类 的手法来实现

场景二：

样貌相同的亲兄弟，具有共同爱好的朋友，具有相同技能的同事；

对于这种彼此之间的关系的描述，我们可以抽取一个抽象类作为他们之间的共同点，然后进行继承；

场景三：

小明会打羽毛球，小红也学会了打羽毛球， 我们可以把会打羽毛球这项技能抽取出来 如何实现呢

我们可以写一个打羽毛球的interface ，然后由 小明和小红分别来实现；他们可以有各自不同的打法；所以接口也是抽取共同点的一种方式，但是他没有具体的实现方式，只是大概的说明会这项技能而已；

六大原则

根据一个实例来讲解这六大原则；

我们要设计一个 主人（具有领养宠物的能力）要领养一只宠物（不同的宠物有不同的叫的方式） 这件事；

单一职责原则：

我们想到的就是设计 一个 host 类 里面具有一个 adopt（animal）的方法；
一个animal类，里面具有 eat（），drink （） ，say（） 的方法；
按照这种设计思路：

public class Host {
    public void adopt(Dog dog){
        Log.i("", "i get dog");
    }
}
public class Animal {
    public void eat(String kind) {
        if (kind.equals("cat")) Log.i("", "吃鱼");
        if (kind.equals("dog")) Log.i("", "吃骨头");
    }

    public void drink(String kind) {
        if (kind.equals("cat")) Log.i("", "喝鱼汤");
        if (kind.equals("dog")) Log.i("", "喝骨头汤");
    }
}

因为不同的鸡鸭鹅🐶有不同的吃喝拉撒的方式，单写宠物这个类要兼容这些小分类； 可以想象要加多少if语句；

这种设计方法 ，没有将设计进行细化到具体分类，而是用一个类包含了这些分类，却使内部结构过于融合；违背了单一职责原则：所以在设计的时候一定要将设计的对象落实到最小的粒度；

单一职责原则：不要存在多于一个导致类变更的原因

里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何父类可以出现的地方，子类一定可以出现。 也就是说，利用子类来代替父类，不会影响原来的程序的任何功能； 这样才能很好的拓展功能；

根据这些出现的原则，我们进行重新设计，将annimal的功能进行抽取出来， 然后由不同的动物来实现这个interface；

public interface Animal {
    public void eat();

    public void drink();
}
public class Dog implements Animal{
    public void eat() {
        Log.i("", "吃骨头");
    }

    public void drink() {
        Log.i("", "喝骨头汤");
    }
}

然后呢？host部分应该如何写？

public class Host {
  public void adopt(Dog dog){
    Log.i("", "i get dog");
}

public void adopt(Cat cat){
    Log.i("", "i get cat");
}
}

这样的话，得要写多少adopt方法啊，所以我们可以利用接口向上兼容的特点和依赖倒置的原则来实现；

  public void adopt(Annimal animal){
  //todo 进行领养
}


} 

依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象

领养方法做为高层模块没有直接依赖猫猫狗狗等低层模块，依赖了其抽象，扩展性棒棒的。

接口隔离原则：客户端不应该被强迫地依赖那些根本用不上的方法。也就是interface 不能融合度太高。要有针对性实现；

、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。在这个例子中，加一个防疫站的对象，
防疫站 --了解—主人—知道自己养的宠物；
就没必要 防疫站 也拥有 对所有宠物的 引用；

开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

感觉这个原则容易看懂，最难做到。白话就是不要改你以前写的代码，你应该加一些代码去扩展原来的功能，来实现新的需求。好处很好理解，改原来的代码很容易影响原来的功能，特别是接手别人的代码，不理解原先业务场景的情况下。关于‘不要动之前的代码’感觉槽点无数啊，看自己写的代码想吐有木有？别人的代码简直…?之前哪里会想到会有这种鬼需求？