- 2
- 0
- 约5.49千字
- 约 23页
- 2017-12-19 发布于江苏
- 举报
面向对象设计中的大原则
在本单元重点了解如下知识点 单一职责原则(SRP) 接口隔离原则(ISP) 依赖倒置原则(DIP) 开放-封闭”原则(OCP) Liskov替换原则(LSP) 如何正确地进行类的设计 ——遵守面向对象设计中的“五大原则” 面向对象设计和编程概述 1、面向对象设计(OOD)和面向对象编程语言(OOPL) Object-Oriented Programming Language可以提高程序的封装性、复用性、可维护性,但仅仅是“可以”。 让我们开始涉猎软件系统设计的思想、原则和模式方面的内容… Robert C.Martin在《敏捷软件开发——原则、方法与实践》一书中总结出了“单一职责原则”。 让我们先从“单一职责原则”开始吧… 2、能不能真正实现OOD和OOPL所体现出的这些“优点”? 取决于设计和编程人员具体“如何做”。 3、那么如何能够达到如此“境界”? 有什么设计思想、设计原则和设计模式吗? 1、什么是SRP(Single-Responsibility Principle) 一个类应该仅有一个引起它的变化的原因(职责),这条原则也称为类设计的“高内聚性原则”。 少管闲事,专心做一件事情!“一心无二用”! 它指导我们如何提高代码的可重用度! 你认为该JSP页面有什么问题吗? 单一职责原则 (l)含义之一 避免相同的职责(也称为功能)分散到不同的类中实现 (2)含义之二 也应该要避免一个类承担过多的职责。 2、为什么要遵守单一职责原则 (1)可以减少类之间的耦合 你知道为什么“螺钉”的可重用性高! 主要的责任在“方丈” 当需求变化时,只修改一个类,从而也就隔离了变化; 如果一个类有多个不同的职责,它们就耦合在一起,当一个职责发生变化时,可能会影响其它的职责。 (2)不遵守单一职责原则的后果 会影响到对该类的复用性。 当只需要复用该类的某一个职责时,但由于它和其它的职责耦合在一起,也就很难分离出。 (3)遵守单一职责原则的示例 上面的图示表示,在系统的持久层的设计中,将实现数据库连接和数据库访问操作相互分离;由两种不同形式的类承担。 而如果将它们耦合在一起(数据库连接、数据库CRUD操作和数据库连接释放等),将导致“数据连接”的职责在被重用时,将出现问题!拔出萝卜带出泥! 3、遵守单一职责原则的各种GOF设计模式 类的设计主要工作是“发现职责”并“分离职责”! (2)模板方法模式的应用 (1)工厂模式的应用 分离对象的“创建”和对象的“使用”方面的职责。 分离 “共性功能实现”和“个性扩展”方面的职责。 (3)命令模式的应用 分离“命令的请求者”和“命令的实现者”方面的职责。 (4)代理模式的应用 分离 “服务的请求者”和“服务的提供者”各自方面的职责; 应用业务代理类的主要的目的是降低客户端与业务组件之间的紧密关联性和提高业务功能组件类的安全性。 希望大家掌握对这些基本的模式的具体应用! 4、遵守单一职责原则的系统架构设计 (1)单一职责原则不只是对类设计有意义,对以模块、子系统为单位的系统架构设计同样也有意义 一个模块、子系统也应该仅有一个引起它变化的原因,如MVC所倡导的各个层之间的相互分离其实就是单一职责原则在系统总体设计中的应用。 (2)Struts2框架中应用代理模式的示例 1、接口隔离原则(ISP)的具体体现 (1)一个类对另外一个类的依赖性应当是建立在最小的接口上 ISP可以达到不强迫客户(接口的使用方)依赖于他们不用的方法——在接口设计中应该保证,接口的实现类应该只呈现为单一职责的角色(遵守SRP原则); ISP还可以降低客户之间的相互影响——当某个客户程序要求提供新的职责(需求变化)而迫使接口发生改变时,影响到其他客户程序的可能性会最小。 它指导我们如何正确地进行接口设计! 接口隔离原则 (2)客户端程序不应该依赖它不需要的接口方法(功能) 比如在应用继承时,由于子类将继承父类中的所有可用的方法;而父类中的某些方法,在子类中可能并不需要,但也将被父类强迫使用?! 因此,谨用继承! 2、对接口的污染(过于臃肿的接口设计是对接口的污染) (l)接口的污染(Interface Contamination) 一个没有经验的设计师往往想节省接口的数目,将一些功能相近或功能相关的接口合并。 (2)所谓接口污染就是为接口添加了不必要的职责 如果开发人员在接口中增加一个新的功能方法的主要目的只是为了减少接口的实现类的数目,如此设计将导致接口被不断地“污染”并“变胖”。 (3)软件系统中类的设计是否合理不在乎类本身的数目 接口污染会给系统带来维护和重用等方面的问题。 为
原创力文档

文档评论(0)