人是要讲原则的，设计模式也一样。
设计模式是为了面向对象，好吧我也在努力面向对象。
原则介绍（SOLID）
1.单一职责原则（Single Responsibility Principle）
一个类应该有且仅有一个引起它变化的原因
here should never be more than one reason for a class to change
就像古代打仗靠将军，现在战争靠参谋部。避免牛类的存在，转而采用模块化、精细化。对单一模块的修改，不扩散到其他模块。
2 开闭原则(Open Closed Principle)
对扩展开放，对修改关闭
software entities should be open for extension but closed for modification
在相同指挥架构下，你可以创建步兵、骑兵、水兵，但不建议在步兵中安插骑兵。
通过抽象+继承/组合实现封装和扩展，如策略模式
3 里氏替换原则（Liskov Substitution Principle，LSP）
父类的对象可以被子类的对象替换，而程序的行为不会发生变化
步兵、骑兵都是军队的子类，军队执行任务，可以被具体的军种执行，而不产生偏差。
在策略模式中，行为类的接口是通过父类定义，具体实现中，可以用子类来实例化或者替换
4 接口隔离原则（Interface Specified Principle，ISP）
客户端不应依赖它不需要的接口
接口隔离原则简单来说就是合成营的思路，有多个专职兵种所组成的作战单位，每个独立兵种各自独立迭代，
5 依赖倒置原则（Dependency Inversion Principle，DIP）
高层模块不应依赖于底层模块，都应依赖于抽象/接口
抽象不应依赖于细节，细节应依赖于抽象
将军给部队下命令，只需要喊一句：刘亚楼，你记一下，我做如下部署调整。至于进一步派哪些人，那些装备，怎么打，高层就不管了。细节依赖抽象，你不能在步兵中找到航母，也不会在空军中找到重型火炮。
原则思辨
设计原则，延续了软件的一向做法，“抽象+封装”：
// 尚未理解透彻，待后续改进
单一原则描述了抽象的粒度，只有单一变化；
开闭原则描述了抽象的稳度，可扩展，禁改变；
依赖倒置描述了抽象的使用，源于现实高于现实；
接口隔离描述了抽象的关系，最小互扰原则；
里氏替换原则是抽象的封装，
