设计模式，我的理解就是一代代前辈们在解决日常工作中的各个场景的问题中，找到的最优的问题的解决方案，或者说解决套路。
说到设计模式的六大原则，其实也都是前辈们总结出来的一个好的项目所具备的共性，就是需要你的代码是满足这六个规则的，才是一个好的代码，才是一个好的设计模式。
但是其实也不绝对，说是原则，实是建议，意思就是在某些场景和逻辑下，不能生搬硬套设计原则，那样只会显得很蠢，起到适得其反的效果，还是需要因地制宜的去思考使用。
下面六大原则中的其中一个原则————单一原则
单一原则比较好理解的，从字面意思就大概清楚他要表达的就是，单独，一个，的意思。
不管是方法、类、类库、解决方案或者是这一个项目都需要符合单一原则。
一个方法，我只处理一个功能逻辑。
一个类，我只实现一个业务或者场景。
一个类库，我的职责就是数据库啊或者工厂或者前端或者帮助类
一个解决方案，就是后台系统就是后台系统，前台就是前台，或者定时服务，或者接口
...
单一性解决的问题就是代码的高耦合性，防止出现多层的逻辑判断，几个业务的重叠，不出现牵一发而动全身的问题，使代码的维护成本降低，提高代码的稳定性。
如果你的代码是多层的逻辑判断或者多业务的重叠，如果你需要修改其中一个逻辑或者业务，就是导致其他逻辑和业务的不稳定，如果都拆分开，有问题也只是修改的地方有问题，不会出现其他逻辑的问题。