设计模式系列（总纲）

摘要：前言关于设计模式，想必大家的第一感觉就是过于高深，有点虚吧。为什么要学习设计模式因为要装逼啊咳咳，大家请忽略前面那句话。处处都是设计模式的体现，所以若想攻下，设计模式是必学的。下节预告单例模式

关于设计模式，想必大家的第一感觉就是过于高深，有点虚吧。相对来说，我们还是更熟悉ssh或者ssm之类的开发框架，一个工具用久了就会熟能生巧，就像刷漆工，时间长了也知道如何刷的一手漂亮的好墙。我们把springmvc用的很溜，把mybatis用的很溜，但这只是一个合格的程序员应该具备的能力之一。于是我们便成为了代码工人，想站在更高角度去设计，设计模式是必不可少的。

废话那么多，我们直接进入正题呢，到底什么是设计模式呢?我在设计模式之禅上摘抄出这一句话：

设计模式（Designpattern）是一套理论，由软件界的先辈们总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。

因为要装逼啊...咳咳，大家请忽略前面那句话。相信大家都有阅读spring源码的经历吧，看到类层次设计图，为什么会有这么多的接口，这么多的抽象类，这么多实现，心里有一万只草泥马狂奔而过。spring处处都是设计模式的体现，所以若想攻下spring，设计模式是必学的。其次，作为一个coder，最烦的就是需求变更，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更。既然需求不可变更，那如何拥抱变化呢？设计模式给了我们知道，提出了6大原则,在此基础上提出了23种设计模式。如果你通晓了23种设计模式，那你就可以站在一个更高的层次去赏析程序代码，完成从代码工人到架构师的转变~>~.

描述：应该有且仅有一个原因引起类的变更

相信大家已经很不屑了，切，这么简单的东西还拿出来说。可是道理简单实现难啊。下面我给大家示例一些代码:
    public interface IUserInfo {
    
        void setUserName(String name);
    
        void setUserAge(int age);
    
        void walk();
    
        void seeMovie();
        
        void addRole(Role role);
    }
    
相信初级程序员都不会犯这样的错，将用户信息和用户行为放在同一个类里。最佳的做法就是将用户信息和用户行为分开管理，加角色动作也应该放在相应的实现类里。这是我临时想的例子，虽然很简单，但足以表达单一原则的意思。单一职责原则最难划分的就是职责，职责没有量化的标准，职责划分的过于细，类的数量会暴增，系统复杂度会以指数趋势增长，所以建议是接口一定要做到单一职责，累类设计尽量做到单一职责。

描述：所有引用基类的地方必须能透明地使用其子类的对象。

java与c++不同，java是一门单根继承的语言。使用extend关键字声明继承，若不使用，则代表继承Object。子类继承父类，会拥有父类的方法和属性，很多开源框架的扩展接口都是通过继承父类来完成的。通过这个特性，我们明白只要父类存在的地方，我们都可以替换成子类，并且编译器不会报错。但是java允许子类重写父类方法，这种子类的个性化有时会严重违背里氏替换原则.给大家上个示例:

    public class AnyClazz{
        //有某一个方法，使用了一个父类类型
        public void someoneMethod(Parent parent){
            parent.method();
        }
    }
    
    public class Parent {
    
        public void method(){
            System.out.println("parent method");
        }
    }
    
    public class SubClass extends Parent{
    
        //结果某一个子类重写了父类的方法，说不支持该操作了
        public void method() {
            throw new Exception();
        }
        
    }
    
    public class Test{
    
        public static void main(String[] args) {
            AnyClazz anyClazz = new AnyClazz();
            anyClazz.someoneMethod(new Parent());
            anyClazz.someoneMethod(new SubClass());
        }
    }

程序运行结果肯定会报错，这就相当于我们埋了一个雷，子类复写父类方法，编译期不报错，运行期就会报错。所以建议在项目中使用此原则时，应尽量避免子类的个性，一旦子类有个性，子类和父类的矛盾将可能直接破坏整个程序。

描述：面向接口编程。

在Java中的语言表现就是:模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类发生的。接口和抽象类不依赖于实现类。实现类依赖接口或抽象类。简而言之，就是之前的描述~~。给大家举个例子:

     public class Cooker {
        public void work(){
            System.out.println("我会做饭");
        }
    }
    public class Boss {
    
        public void recruitPerson (Cooker cooker){
            cooker.work();
        }
    }
    public class Test {
        
            public static void main(String[] args) {
                Boss boss = new Boss();
                boss.recruitPerson(new Cooker());
            }
        }
        运行结果：我会做饭

上面代码一个大老板刚开了一个超市，在招厨师。假如我们要是招大堂经理怎么办？创建经理类，在boss中增加招经理的方法同时在test中修改。这样改好吗？仅仅是需求改了一点点，我们就要在所有代码里进行一些改动，这代价也太大了吧，耦合性忒高了~
不要着急，依赖倒置原则可以帮我们解决这个问题，它可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码可读性和维护性。修改之后的例子如下:

public interface IWorker {

    void work();
}

public class Cooker implements IWorker {
    @Override
    public void work(){
        System.out.println("我会做饭");
    }
}

public class Manager implements IWorker {
    @Override
    public void work() {
        System.out.println("糊弄老板，指挥其他人干活");
    }
}

public interface IBoss {
    void recruitPerson(IWorker iWorker);
}

public class Boss implements IBoss{

    @Override
    public void recruitPerson(IWorker iWorker) {
        iWorker.work();
    }
}

public class Test {

    public static void main(String[] args) {
        Boss boss = new Boss();
        IWorker iWorker = new Manager();
        boss.recruitPerson(iWorker);
    }
}
运行结果：
糊弄老板，指挥其他人干活

咋一看，类变得更多了..使用技术总是要有点成本的吗，但假如以后我们在增加招理货员，招收银员等等改动就小了。其实这个原则的本质就是通过抽象是各个类和模块的实现独立，不互相影响，实现松耦合。

描述:接口尽量细化，同时接口中方法尽量少。

看到上面的描述可能会有点疑惑，这个和第一个的小姐姐(单一职责原则)有点像啊。单一职责衡量的是类的和接口职责要单一，对，是职责！而接口隔离原则就只是要求接口的粒度尽可能的小，最好就是一个接口一个方法（这是完美符合接口隔离原则的），不过这样做的话是明显要被其他小伙伴干死的(2333~~~)。接口粒度太小，接口数就会暴增，开发人员呛死在接口的海洋里，接口粒度太大，灵活性降低，无法提供定制服务。给大家举个例子:

//美食
public interface ICate {

    void goodLool();
    void niceTaste();
    void cleanFood();
}

public class Cate implements ICate{

    @Override
    public void goodLool() {
        System.out.println("色相看起来很好O(∩_∩)O哈哈~");
    }

    @Override
    public void niceTaste() {
        System.out.println("吃起来，味绝了(*^▽^*)");
    }

    @Override
    public void cleanFood() {
        System.out.println("食材很干净，食用放心");
    }
}

public abstract class AbstractPerson {

    protected ICate iCate;

    public AbstractPerson(ICate iCate) {
        this.iCate = iCate;
    }

    abstract void eat();
}

public class Person extends AbstractPerson {
    public Person(ICate iCate) {
        super(iCate);
    }

    @Override
    void eat() {
        iCate.cleanFood();
        iCate.goodLool();
        iCate.niceTaste();
    }
}

public class Test {

    public static void main(String[] args) {
        ICate iCate = new Cate();
        AbstractPerson abstractPerson = new Person(iCate);
        abstractPerson.eat();
    }
}

运行结果：
食材很干净，食用放心
色相看起来很好O(∩_∩)O哈哈~
吃起来，味绝了(*^▽^*)

    上面的例子我去吃美食，我对美食的标准是看起来，闻起来像，吃起来放心（吃货up!up!）。可是每个人对美食的标准都是一样的，你总不能因为臭豆腐闻起来很臭就不是美食吧。可是现在接口定义了只有三个条件都满足才能叫美食，这个该怎么办？难道要再扩展一个美食接口，只定义味道标准，可是我们的抽象类依赖的是ICate接口，我们的person又怎么只根据味道去分辨是不是美食呢？我们采用接口隔离原则去细化接口，示例如下:

public interface IGoodLookCate {

    void goodLook();
}

public interface IGoodTasteCate {


    void niceTaste();
    void cleanFood();
}

public class Cate implements IGoodLookCate,IGoodTasteCate{

    @Override
    public void goodLook() {
        System.out.println("色相看起来很好O(∩_∩)O哈哈~");
    }

    @Override
    public void niceTaste() {
        System.out.println("吃起来，味绝了(*^▽^*)");
    }

    @Override
    public void cleanFood() {
        System.out.println("食材很干净，食用放心");
    }
}

通过这样的重构后，不仅是要好吃的美食还是要好看的美食，都可以保持接口的稳定。当然你如果要说美食的标准又变了，接口还得改。没错，但是设计是有限度的，不能无限考虑未来，不然会陷入到过度设计的泥潭当中。

描述：一个对象尽量不要知道太多关于其他对象的事

这个原则的核心观念就是类间解耦，低耦合。通俗一点来讲就是1.只和朋友交流2.朋友之间也是有距离的。举个例子说明下吧:

public class Goods {
}

public class Worker {


    public void sendGoods(List list){
        System.out.println("送货喽："+list);
    }
}

public class Boss {
    private static final List list = new ArrayList();

    static {
        list.add(new Goods());
        list.add(new Goods());
        list.add(new Goods());
    }

    public static void main(String[] args) {
        Worker worker = new Worker();
        worker.sendGoods(list);
    }

}

工人送货的场景，老板和工人是直接关系，工人和货物是直接关系，但是代码中老板和货物也搅在了一起，出现了过多依赖，破坏了老板类的健壮性，已经违反了迪米特法则。正确做法应该是将货物的逻辑抽取到工人当中（因为非常简单，就不上代码示例了）。朋友之间也是有距离的应当如何理解呢？假如类A提供了getA(),getB(),getC()三个方法，类B在逻辑内对ABC三个方法进行调用或者根据其返回值决定逻辑，这样也违反了迪米特法则，正确做法应是将对ABC三个方法调用的逻辑抽取封装到A中，同时将ABC三个方法进行私有化。

描述：对扩展开放，对修改关闭

开闭原则是六大原则里的精神领袖，也是最虚的原则。前面五个原则就是对开闭原则的具体解释。意思就是现在的系统中，不需要修改原有的代码，只需要扩展一些新的实现就可以搞定。但是没有任何一个系统可以做到，哪怕是spring也不可以，虽说他的扩展性已经强的{{BANNED}}。

以上6个原则是为了之后23种设计模式的描述，基本上都是我自己的理解，或许形容有好有差，不需要在意，各位完全可以有自己的理解。