面向对象设计的基本原则

发现竟然不能信口即来，惭愧，摘文章贴之：

 

设计的普遍规律，不只单讲如何设计类，向上到整个组件的设计，向下到类中单个方法的设计

 

单一职责原则——SRP

就一个类而言，应该仅有一个引起它的变化的原因

 

原则

最简单，最单纯的事情最容易控制，最有效
类的职责简单而且集中，避免相同的职责分散到不同的类之中，避免一个类承担过多的职责
减少类之间的耦合
当需求变化时，只修改一个地方

组件

每个组件集中做好一件事情
组件的颗粒度
发布的成本
可重用的成本

 

方法

避免写臃肿的方法
Extract Method

 

重构

Move Field/Move Class
Extract Method/Extract Class

 

最简单的，也是最难以掌握的原则

 

实例分析

Olite

开放封闭原则——OCP

软件实体（类，模块，函数）应该是可以扩展的，但是不可修改的

 

原则

 

对扩展是开放的，当需求改变时我们可以对模块进行扩展，使其具有新的功能
对更改是封闭的，对模块扩展时，不需要改动原来的代码
面对抽象而不是面对细节，抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。

方法

条件case   if/else 语句

 

重构

Replace Type Code With Class
Replace Type Code With State/Strategy
Replace Conditional with polymorphism

 

实例

插件
数据驱动的OrderCycle

 

Liskov替换原则 LSP

子类型必须能够替换它的基类型

原则

主要针对继承的设计原则
所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。
派生类必须满足基类和客户程序的约定
IS-A是关于行为方式的，依赖客户程序的调用方式

 

重构

Extract Supper Class

 

实例

长方形和正方形

 

依赖倒置原则DIP

a：高层模块不应依赖于底层模块，两者都应该依赖于抽象
b：抽象不应该依赖于细节，细节应该依赖于抽象

 

原则

如何解释倒置
高层依赖底层，重用变得困难，而最经常重用的就是framework和各个独立的功能组件
高层依赖底层，底层的改动直接反馈到高层，形成依赖的传递

面向接口的编程

 

实例

Ioc模式
DomainObject / DomianObjectDataService

 

参考

《敏捷软件开发 原则、模式与实践》

 

http://microhelper.blogdriver.com/microhelper/432102.html