软件工程面向对象的设计原则资料

1、 面向对象的设计原则和设计模式北京化工大学计算机系袁国栋 面向对象的设计原则一个好的系统设计应该包括至少三个性质：可扩展性，和插入性和灵活性。面向对象设计的原则 开闭原则(Open-Closed Principle OCP 一个软件实体应该对扩展开放，对修改关闭。模块设计时，使得该模块可以在不被修改的前提下被扩展。也即就当可以在不必修改源代码的情况下改变这个模块的行为。“不能修改而可以扩展”是不允许更改系统的抽象层，而允许扩展的是系统的实现层。 如何做到既不修改，又可以扩展？抽象化让模块依赖于一个固定的抽象体，这样它就是不可以修改的；同时，通过这个抽象体派生，就可以扩展此模块的行为功能。这样设

2、计的程序只通过增加代码来变化而不是通过更改现有代码来变化。 OCP 实例以上函数的工作是在制订的电脑部件数组中计算各个部件价格的总和。若Part 是一个基类或接口且使用了多态，则该类可很容易地来适应新类型的部件，而不必对其进行修改。其将符合 OCP 但是在计算总价格时，若财务部颁布主板和内存应使用额外费用，则将如何去做。下列的代码是如何来做的呢？ 每当计价策略发生改变，我们就必须修改Part 的每个子类 采用一个PricePolicy 类，通过对其进行继承以提供不同的计价策略；所做的就是将问题推迟到另一个类中，将“变化”封装在PricePolicy 类里面；但是使用该解决方案，可通过改变Par

3、t 对象，在运行期间动态地来设定计价的策略。 单一职责原则(SRP: The single responsibility principle就一个类而言, 应该仅有一个引起它变化的原因, 如果你能想到多于一个的动机去改变一个类, 那么这个类就具有多于一个的职责. 应该把多于的职责分离出去, 分别再创建一些类来完成每一个职责. 系统中的每一个对象都应该只有一个单独的职责，而任何对象所关注的就是自身职责的完成 实例DBManager 类对数据库的操作和用户权限的判别封装在一个类中实现public void Add(if (GetPermission(m_id = CanAdd"Conso

4、le.WriteLine("管理员可以增加数据。" 权限判断的职责、数据库操作的职责被无理的实现在一个类中，权限的规则变化和数据库操作的规则变化，都有可能引起DBManager 修改当前代码。按照单一职责原则，一个类应该只有一个引起它改变的原因。所以我们选择以合适的方式来重构有缺陷的设计，在此显然可以通过实现一个Proxy 模式来解决职责交叉的问题 public class DBManager :IDBAction private string m_id=string.Empty;public DBManager(stringid m_id=id; IDBAction Me

5、mbers public class DBManagerProxy :IDBAction private IDBAction dbManager;public DBManagerProxy(IDBActiondbAction dbManager =dbAction; public string GetPermission(stringid return string.Empty; IDBAction Members public class DBClient static void Main(stringargs IDBAction dbManager =new DBMana gerProxy

6、(newDBManager("CanAdd"dbManager.Add(; 一个软件实体如果使用的是一个基类的话那么一定适用于其子类，而且它察觉不出基类对象和子类对象的区别。也就是说，在软件里面，把基类都替换成它的子类，程序的行为没有变化。LSP 是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。长方形和正方形实例 Dependency Inversion Principle高层模块不应该依赖于低层模块, 二者都应该依赖于抽象抽象不应该依赖于细节, 细节应该依赖于抽象 高层模块包含了一个应

7、该程序中的重要的策略选择和业务模型，正是这些高层模块才使得其所有的应用程序区别于其他，如果高层依赖于低层, 那么对低层模块的改动就会直接影响到高层模块, 从而迫使它们依次做出改动。 缺点：耦合太紧密，Light 发生变化将影响 ToggleSwitch怎么办？将Light 作成Abstract ，然后具体类继承自Light优点：ToggleSwitch 依赖于抽象类Light ，具有更高的稳定性，而BulbLight 与TubeLight 继承自Light ，可以根据" 开放封闭" 原则进行扩展。只要Light 不发生变化，BulbLight 与TubeLight 的变化就

8、不会波及ToggleSwitch 。 如果用ToggleSwitch 控制一台电视就很困难了。总不能让TV 继承自Light 吧。 任何变量都不应该持有一个指向具体类的指针或者引用任何类都不应该从具体类派生(始于抽象, 来自具体 任何方法都不应该覆写它的任何基类中的已经实现了的方法 定义客户端不应该依赖它不需要的接口类间的依赖关系应该建立在最小的接口上一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。 接口要尽量小这是接口隔离原

9、则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。根据接口隔离原则拆分接口时，首先必须满足单一职责原则。 接口要高内聚高内聚就是要提高接口、类、模块的处理能力，减少对外的交互。具体到接口隔离原则就是，要求在接口中尽量少公布public 方法，接口是对外的承诺，承诺地越少对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。 定制服务定制服务就是单独为一个个体提供优良的服务。接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个度只能根据经验和常识判断，没有一个固化或可测量的标准 接口设计是有限度的 迪米特原则一个软件实体应当尽可能少的其他实体发生相互作用。模块之间的交互要少。这样做的结果是当系统的功能需要扩展时，会相对更容易地做到对修改的关闭。一个对象应当对其他对象有尽可能少的了解。 迪米特原则的具体操作 优先考虑将一个类设置成不变类。不变类易于