我的设计模式.docxVIP

『Single Responsibility Principle』单一职责原则：单一职责原则的核心精神是：一个类，或者一个接口，最好只做一件事情，当发生变化时，他只能受到单一的影响；因为职责过多，可能引起变化的原因将会很多，这样导致职责和功能上的依赖，将严重影响其内聚性和耦合度，混乱由此而生。单一职责的原则在现实生活中早就实践于现代公司体制与工业生产上，如公司的各个部门职责分明相互独立，生产流水线的某一环节只需关注上螺丝，而另一环节只做零件组装等等；这一原则使庞大的系统组合起来还能各司其职，井井有条，即使某个部门、某个环节出了问题或需要改动，你只需去动那个要变动的地方即可，从而避免因职责功能不明而导致不必要的的混乱。同样，程序代码的设计也是如此，功能和职责单一化也是衡量代码优良的一个标准；交杂不清的职责和功能将使得代码看起来特别别混乱、别扭且一发而动全身，更严重的是在日后的维护中你得花更多的时间去理清他的逻辑，并且这地方的变动几乎是必然引起让人头痛的BUG，你将花费更多的精力，承担更多的风险！在代码工程的实施中，遵循单一职责原则将会带来诸多好处：类的复杂性将降低，简单明细的代码将使可读性将大大提高，自然而然可维护性亦将同步提高，可维护性提高将预示着因变更引起的风险会大大降低，最重要的前边的好处将会是你工作轻松愉悦、思路清晰、远离脑爆头大……专注即高效，单一既轻松，人事皆如此。『Liskov Substitution Principle』里氏替换原则里氏替换原则的核心精神是：在使用基类的的地方可以任意使用其子类，能保证子类完美替换基类；这一精神其实是对继承机制约束规范的体现。在父类和子类的具体实现中，严格控制继承层次中的关系特征，以保证用子类替换基类时，程序行为不发生问题，且能正常进行下去。里氏替换原则主要发力点是继承基础上的抽象和多态，具体就是子类必须实现父类的方法，是重写；这里要注意重写（Override）与重载（Overload）的区分，即使参数的数据范围发生变化，也能将重写变成重载！而你原本只是想把所继承的方法完善的具体点儿！如果是这样的话绝对会引起以后业务逻辑的混乱。里氏替换原则是关于继承机制的设计原则，违反里氏替换原则将会使继承变的一塌糊涂；而遵循里氏替换原则能够保证系统具有良好的的拓展性，我们可以随时根据需要增改不同的子类，这将大大增强程序的健壮性，让版本的升级可以做到非常好的兼容；同时基于多态的抽象机制，能够很好的减少代码冗余，避免运行期的类型判别等；而在项目的实施中不同的子类对应着不同的业务，使用父类做参数，不同子类可以轮番上阵，必然强大！*在此重温【重写与重载】多态性是面向对象编程的一种特性，和方法本身无关。方法的重载，就是同样的一个方法能够根据输入数据的不同，做出不同的处理——有不同的参数列表，甚至不同的返回值（静态多态性）方法的在重写，是子类继承自父类的相同方法，输入参数一样，但要做出有别于父类的操作，要覆盖父类方法。——相同参数，相同返回值，不同实现（动态多态性）用好重写和重载可以设计一个结构清晰而简洁的类，重写和重载在编写代码过程中的作用非同凡响。『Interface Segregation Principle』接口隔离原则接口隔离原则的核心精神是：尽量使用多个专门的单一的小接口，避免庞大的总接口；专业点的说法是类间的依赖关系尽量建立在最小的接口上。接口尽量的小，但是小不是说一个接口一个方法，小也要不违背单一职责原则；接口应该严格体现内聚性，尽可能的少公布public方法，在开发中不能让功能繁琐的大接口出现；一个类对另一个类的依赖应该建立在最小的接口上，不能强迫与之无关的方法，否则将会造成接口污染。遵循接口隔离原则将使接口有效的将细节和抽象隔离，体现了对抽象编程的一切优点，接口隔离强调接口的单一性。而大接口因强制要求实现类完成它所有的并非必须的方法、属性等，从而造成严重的设计浪费，对以后的维护和改动带来难以衡量的困难，对“接口”这个概念造成极大的侮辱。但在现实中，如何把握接口越小越好，这个度很难界定，颗粒度小固然灵活，但同时会造成结构的复杂化，以下有几个把握规则可以参考：一个接口只服务于一个子模块或业务逻辑，服务定制；通过业务逻辑压缩接口中的public方法，让接口看起来精悍；已经被污染了的接口，尽量修改，如果变更风险太大，则用适配器模式进行转化处理；根据具体的业务，深入了解逻辑，用心感知去控制设计思路。具体如何实施接口隔离，主要有两种方法：1、委托分离，通过增加一个新的接口类型来委托客户的请求，隔离客户和接口的直接依赖，注意这同时也会增加系统的开销；2多重继承分离，通过接口的多重继承来实现客户的需求，这种方式相对较好。具体的使用，视情况而定。怎么准确的实践接口隔离原则呢？有一本书上写得非常好：实践、