个人设计模式总结

设计模式是前人从一些常见复杂业务场景中抽象出来的、经过不断验证的、可以降低复杂度的软件编写解决方案，它比较难懂，没有经过一定岁月的积累和理解的人，很难在工作中将它运用自如且真正起到降低复杂度的目的，要么过度设计，反而加大了复杂度，要么四不像，不切合实际业务。

我对设计模式不算特别理解，但在业务中也有点小应用，本博客就把我的一些理解写下来，与大家共同学习提高。

我觉得具体的设计模式还是容易学习的，只是不太好应用于实际开发中，反而设计原则更容易应用于实际开发中。

设计原则第一条单一职责

单一职责原则在开发大型应用程序中是非常重要的一点，有过几年开发经验的朋友，一定会有这样的体会：程序越庞大，代码量越多、逻辑越复杂，就越不容易理清头绪，如果此时你再把代码一股儿脑写在一个大型函数里面，看的人特别难受，维护和修改会非常头疼，这种情况多见于接手别人的代码。
所以，要想解决这个问题，最好的方法是拆分函数、拆分类、拆分模块，按照一个函数、一个类、一个模块只负责做一件事情的原则来编写代码，这样会让你的思路变得清晰。

这个原则理解起来非常简单，难的在于如何拆分函数、如何拆分类、如何拆分模块、如何保证职责单一、怎么才叫做职责单一。要想应用好这个原则，唯一我能想到的方法就是增加经验，没有几年对业务的理解、对这个原则的实践经验，很难真做到单一职责。

我这里举一个非常简单的例子，举这个例子的目的主要是让读者理解一下什么是单一职责原则（说实话，这个单一职责也要看业务场景，且每个人的理解也是不同的）。
例子：编写一个函数，计算两个数的和
这个例子太简单了，简单到所有人都可以在半分钟写出如下代码

public int add(int a,int b){
    return a + b;
}

这个函数其实职责非常简单，但是随着业务的发展，它的职责就会变得不单一，比如，业务需求变化如下：要求这个函数能计算任意2个数的任意一种运算。这下该怎么办呢？别急，这个可以使用即将说到的策略模式来解决。

设计模式策略模式

策略模式的本质是将每一种策略，官方叫算法，封装起来，且多个策略可以互相替换而对使用者透明，其本质可以理解为C++中的多态。比如上面的题目，其本质是计算2个数的某种运算，这种运算是变化的，而2个数是固定的，于是可以这样设计

//接口，定义2个数的计算结果
public interface Calculate{
       
   int calculate(int a,int b)
}

//定义加法
public class Add implements Calculate{

     public int calculate(int a,int b){
          return a + b;
     }
}

//定义减法
public class Sub implements Calculate{

     public int calculate(int a,int b){
          return a - b;
     }
}

每一个计算规则的实现是独立的，且只做一件简单的事情，加法函数不会知道如何去实现减法，减法函数也不会知道如何实现加法，这就是典型的应用单一职责的场景。

在实际工作中，如何抽象出这个接口是需要慢慢积累经验的，博客中介绍的例子非常简单，读者一看就明白，而在实际工作中的东西就不那么简单了，这就是应用设计模式的难点所在。