面向对象软件设计：SOLID 原则
Single-responsibility principle
A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.
"Software entities ... should be open for extension, but closed for modification."
"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also design by contract.
Interface segregation principle
"Many client-specific interfaces are better than one general-purpose interface."
Dependency inversion principle
One should "depend upon abstractions, [not] concretions.
一：单一职责原则[Single-responsibility principle]---SRP
解释：一个类或者模块只是负责完成一个职责，通俗的理解就是一个模块，类，方法不要承担过多的任务。
设计类应该遵循：设计粒度小，功能单一的类。
实际开发中：不必严格遵守，但是可以设计一个粗粒度的类，随着业务的发展，再进行重构。
实际开发中可以按照以下参考意见：
1:依赖过多的其它类，或者代码直接依赖关系过于复杂时，不符合高内聚低耦合的设计思想时，就可以考虑对代码进行拆分。
2：类的名称或者实际的功能关系不大或者没关系，可以进行更加细粒度的拆分，把无关的功能独立出去。
3：类的代码函数过多，影响可读性和代码维护时，可以对代码进行方法级别的拆分
二 ：开闭原则[Open–closed principle]---OCP
解释：软件实体(模块，类，方法等)应该对扩展开放，对修改关闭，通俗理解就是添加一个功能应该在已有的代码上进行扩展，而不是修改已有的代码。
开闭原则的目的是为了代码的可扩展性，并且避免了对现有代码的修改而给软件带来风险。
实际开发中可以按照以下参考意见：
1:业务驱动的系统,需要充分了解业务需求，找到对应的扩展点。 如果不确定因素过多，需求变化过快，则可以对一些比较确定的，短期内就可能会扩展的，通过设计扩展点，能明显提高代码的稳定性和开发效率的地方进行设计。
2;如果是通用型的技术，比如框架，组件，类库，你应该考虑该技术框架如何被用户使用，考虑升级和兼容性问题
- 例子：分析：Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题，也可以从网上下载新的主题。这些主题有共同的特点，可以为其定义一个抽象类（Abstract Subject），而每个具体的主题（Specific Subject）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的。
三：里式替换原则[Liskov substitution principle]----LSP
解释：子类对象能够替换程序中父类对象出现的任何地方，并保证原来的程序的逻辑行为不变以及正确性不被破坏。
子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
可以利用面向对象的多态性来实现，多态和里式替换原则类似， 多态是面向对象的特性，而里式替换原则是一种设计原则，用来指导继承关系中子类该如何设计，子类的设计要确保在替换父类的时候，不改变程序原有的逻辑以及不破快原有程序的正确性。
具体的实现方式可以理解为：
子类在设计时候，要遵循父类的行为约定。父类定义了方法的行为，子类可以改变方法的内部实现[重写]，但是不改变方法原有的行为约定如：接口/方法 声明要实现的功能，对参数值，返回值，异常的约定。
四： 接口隔离原则[Interface segregation principle]----ISP
解释：客户不应该强迫依赖他不需要的接口。
具体的实践可以参考如下：
1：对于接口定义来说，如果某个接口承担了与他无关的接口定义，则说明了该接口违反了接口隔离的原则，可以把无关的接口剥离出去。
2：对于共通的功能来说，应该细分功能点，按需添加，而不是定义一个大而全的接口，让子类去实现。
五：依赖倒置原则[Dependency inversion principle]----DIP
解释：高层模块不要依赖低层模块。高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现，具体实现依赖抽象。
这里的高层模块，从代码的角度来看就是调用者，低层模块就是被调用者。