面向对象设计原则七 - 组合优先于继承

摘要: 组合通过创建一个由其他对象组合的对象来获得新功能的重用方法 新功能的获得是通过调用组合对象的功能实现的 有时又叫聚合 例如:一个对象拥有或者对另外一个对象负责并且两个对象有相同的生命周期。(GOF) 一个对象包含另一个对象集合 被包含对象对其他对象是不可见的并且只能从包含它的对象中访问的特殊组合形式 组合的优缺点优点被包含对象通过包含他们的类来访问 黑盒重用,因为被包含对象的内部细节是不可见的 很好的封装 每个类专注于一个任务 通过获得和被包含对象的类型相同的对象引用,可以在运行时动态定义组合的方式 缺点结果系统可能会包含更多的对象 为了使组合时可以使用不同的对象,必须小心的定义接口 继承通过 阅读全文
posted @ 2011-04-17 23:31 yang3wei 阅读(285) 评论(0) 推荐(0)

面向对象设计原则六 - 针对接口编程,而不是针对实现编程

摘要: 程,而不是针对实现编程接口接口是一个对象中可以被另一个对象调用的一组方法 一个对象可以有多个接口 类型是一个对象的特殊接口 不同的对象可以有相同的类型,一个对象可以有多种不同的类型 一个对象只有通过它的接口才能被其他对象知晓 接口是可插拔的关键 实现继承和接口继承实现继承(类继承)------ 一个对象的实现定义在另一个对象的实现的基础上 接口继承 ------ 描述了一个对象什么时候可以代替另一个对象使用 Java为接口继承提供了专用的结构 - interface Java的接口结构使专注于对象接口的设计更容易实现 接口的优缺点优点客户端不知道他们所使用对象的具体类型 一个对象可以被另一个对 阅读全文
posted @ 2011-04-17 23:30 yang3wei 阅读(789) 评论(0) 推荐(0)

面向对象的设计原则五 - 依赖倒转原则

摘要: 动机在一个应用程序中,我们有一些实现了基础的、主要的操作的底层类和一些封装了复杂逻辑的上层类。实现这种结构的很自然地方式就是,先编写底层类,完成后再编写复杂的上层类。因为上层类是由其他东西定义的,所以这看起来是一种很合理的方式。但是这不是一个灵活的设计,如果我们需要替换一个底层类时会发生什么?让我们以经典的拷贝程序为例,它从键盘读取一些字符,然后把他们输出到打印设备上。包含该逻辑的上层类是Copy类,底层类是KeyboardReader和PrinterWriter。在一个不好的设计中,上层类直接使用底层的类,在这种情况下,如果我们想要把输出定向到新的FileWriter类,就必须修改Copy类 阅读全文
posted @ 2011-04-17 23:26 yang3wei 阅读(238) 评论(0) 推荐(0)

面向对象的设计原则四 - 里氏代换原则

摘要: 动机当我们设计程序模块时,我们会创建一些类层次结构,然后我们通过扩展一些类来创建它们的子类。我们必须确保子类只是扩展而没有替换父类的功能,否则当我们在已有程序模块中使用它们时将会产生不可预料的结果。里氏代换原则表明当一个程序模块使用基类时,基类的引用可以被子类替换而不影响模块的功能。里氏代换原则基类完全能够被子类替代而不影响模块的功能。实例对于多态来说里氏代换原则好像是很显然的事情,例如:Java代码 publicvoiddrawShape(Shapes){ //Codehere. }public void drawShape(Shape s) { // Code here. }对于Shape 阅读全文
posted @ 2011-04-17 23:23 yang3wei 阅读(189) 评论(0) 推荐(0)

面向对象的设计原则三 - 接口隔离原则

摘要: 动机当我们设计应用程序的时候,如果一个模块包含多个子模块,那么我们应该小心对该模块做出抽象。设想该模块由一个类实现,我们可以把系统抽象成一个接口。但是当我们想要添加一个新的模块扩展程序时,如果要添加的模块只包含原系统中的一些子模块,那么就会强迫我们实现接口中的所有方法,并且还要编写一些哑方法。这样的接口被称为胖接口或者叫被污染的接口,使用这样的接口将会给系统引入一些不正确的行为。接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口,应该把胖接口中的方法分组,然后用多个接口代替它,每个接口服务于一个子模块。接口隔离原则不应该强迫客户端依赖于他们不会使用的接口。实例下面是一个违反了接口隔离 阅读全文
posted @ 2011-04-17 23:19 yang3wei 阅读(242) 评论(0) 推荐(0)

面向对象的设计原则二-单一职责原则

摘要: 转载自:http://zjliu.iteye.com/blog/423217动机在本文中职责是指引起变化的原因。该原则表明,如果你有多个原因去改变一个类,那么应该把这些引起变化的原因分离开,把这个类分成多个类,每个类只负责处理一种改变。当你做出某种改变时,只需要修改负责处理该改变的类。当我们去改变一个具有多个职责的类时可能会影响该类的其他功能。单一职责原则一个类应该只受一种变化的影响。单一职责原则简单而直观,但是在实际实现中可能是很困难的。实例假设我们需要一个对象保存email信息,在下面的例子中我们将使用IEMAIL接口。初看起来,一切都很好。但是仔细分析我们会发现我们的IEMAIL接口和E 阅读全文
posted @ 2011-04-17 23:16 yang3wei 阅读(162) 评论(0) 推荐(0)