设计原则概述
提到设计模式通常需要遵循一些设计原则，在设计原则的基础之上衍生了各种各样的设计模式。设计原则是设计要求，设计模式是设计方案，使用设计模式的代码则是具体的实现。
设计模式中主要有六大设计原则，简称SOLID，是由各个原则首字母简称组合而来（两个L算一个，solid稳定的），六大设计模式分别如下：
1）六大设计原则
1. 单一职责原则 （Single Responsibitity Principle）
2. 开放封闭原则 （Open Close Principle）
3. 里氏替换原则（Liskov Substitution principle）
4. 接口分离原则（Interface Segregation Principle）
5. 依赖倒置原则（Dependence Inversion Principle）
6. 迪米特法则（Least Knowledge Principle）
软件开发中，我们要基于这六个原则，设计建立稳定、灵活、健壮的程序。
单一职责原则 （Single Responsibitity Principle）
官方定义：一个类或模块只完成一个职责（或功能）
通俗来说，单一职责原则的定义描述非常简单。一个类只负责完成一个职责或功能，也就是说在类的设计中，我们不要设计大而全的类，而是设计粒度小、功能单一的类。
例如：我们设计一个类包含用户一些操作，又包含了支付的一些操作，那么这个类就不是只做一件事了，就会变的臃肿、复杂，我们应该拆分成多个功能更加单一的粒度更细的类。
场景示例
在一个社交媒体产品中，我们使用UserInfor去记录用户的信息，包含如下属性
请问上面的 UserInfor 类是否满足单一责任原则？
- 观点1: 满足，因为记录的都是和用户相关的信息
- 观点2: 不满足，业务地址信息应该被拆分出来，单独存放
正确答案：根据实际业务场景选择是否拆分
- 如果社交产品只有用户信息，只是用来展示，那么这样设计就没问题
- 如果后面社交产品又添加了电商模块，那么就应该拆分出来
总结：不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都不一样
我们可以写一个粒度粗的类，满足业务要求。随着业务扩展，如果类越来越大，代码越来越复杂，那么我们就要想着去拆分更细粒度的类，
持续重构。
如何判断一个类的职责是否单一？
这里没有什么特别死的规则，都是从实际需求出发，代码是服务于需求的。但是也有一些侧面指标可以参考：
- 类中的代码数、函数、属性非常多
- 类依赖的其他类很多
- 私有方法很多
- 类中有大量的方法都是集中操作类中的几个属性
