1、Java OOP,OO的特性和原则,特性和原则,三大特性 封装、继承、多态 五大原则,三大特性封装,封装：encapsulation 广义：把客观事物封装成抽象的类。 狭义：类可以把自己的属性和方法只让可信的类或者对象操作，对不可信的外部进行信息隐藏。 即：通过访问修饰符来限定访问。 通俗： 属性的封转：通过公有的setter/getter方法访问私有的属性，保证对私有属性的操作的安全性。 方法的封装：该公开的公开，该隐藏的隐藏。 公开的是方法的声明（定义），即（只须知道参数和返回值就可以调用该方法）； 隐藏的是方法的具体实现，即（方法体的具体代码），使方法实现的改变对架构的影响最小化。,三大
2、特性继承,继承：inheritanceJava是单一继承 目的：实现代码的复用。 继承是指这样一种能力：它可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。 通过继承创建的新类称为“子类”或“派生类”。 被继承的类称为“基类”、“父类”或“超类”。 继承的过程，就是从一般到特殊的过程，是is-a的关系。 通俗： 继承后子类自动拥有了父类的属性和方法，父类的私有属性和构造方法并不能被继承。 子类可以写自己特有的属性和方法，以实现功能的扩展，子类也可以覆盖(override)父类的方法（方法的重写）。 注意： 在jdk1.4以前要求方法的覆盖时，需要方法的返回值，参数表
3、，方法名必须严格相同，而在jdk1.5中方法覆盖，子类的中覆盖的方法的返回值可以是父类中被覆盖的方法的返回值类型的子类型。 子类的方法覆盖父类的方法时，表示的访问权限要至少宽于父类。 super和构造方法 super()，表示在子类的构造方法中调用父类的构造方法，只能出现在构造方法的第一句上.在子类的构造方中指明构造父类时调用哪一个父类的构造方法构造父类。 在写类的时候，一定要写默认无参的构造方法，如果一个构造方法的第一句既不是this(),也不是super()时，那么就会在这里隐含的调用他的父类的无参的构造方法，即隐含的有super()。 少覆盖原则： 子类应当尽量少的覆盖父类方法。,继承的
4、展开：is-a和has-a,is-a：继承是is-a 泛化（Generalization） 若在逻辑上B是A的“一种”（a kind of），并且A的所有方法和属性对B而言都有意义，则允许B继承A的方法和属性。 has-a：类中的属性是类 若在逻辑上A是B的“一部分”（a part of），则不允许A从B派生，要用A和其它东西组合出B。 具体分为： 聚合（aggregation） 一种相对松散的关系，聚合类B不需要对被聚合的类A负责。 组合（composition） 更为坚固的关系，A的生命期受B控制。A会随着B的创建而创建，随B的消亡而消亡。 依赖(Dependency) B与A的关系只是一
5、种依赖关系，如果类A被修改，那么类B会受到影响。 可以这么理解： 依赖关系中的类B的其他方法中会用到类A。,三大特性多态,封装可以隐藏实现细节，使得代码模块化；继承可以扩展已存在的代码模块（类）；它们的目的都是为了：代码重用。多态则是为了实现另一个目的：接口重用。 多态：polymorphism 三个前提：子类实例看作是其父类型的对象 子类覆盖父类的方法 里氏替换 调用子类的覆盖的方法 实现多态，有二种方式，静态多态：重载；动态多态：覆盖。 重载，是指允许存在多个同名方法，这些方法的参数表不同（参数个数、类型、顺序不同）。 重载的概念并不属于“面向对象编程”，只是一种语言特性。 重载的实现是：
6、编译时根据方法不同的参数表，对同名方法的名称做修饰，然后这些同名方法就成了不同的方法（至少对于编译器来说是这样的）。对于这些方法的调用，在编译期间就已经确定了，是静态的。重载和多态无关。 覆盖，是指子类重写覆盖父类的方法。 动态的调用属于子类的方法，这样的方法调用在编译期间是无法确定的。 多态的使用 多态用于参数，在方法的参数中传入其父类类型，在运行时会根据实际的运行时类型来在方法中进行相应的操作。 多态用于返回值，在方法的返回值类型上是用其实际返回值的父类型，在使用期返回值时不关心其实际类型。,五大原则？,面向对象设计的原则一共有11种：追求“高内聚、低耦合” 类设计：五项原则 SRP，单一
7、职责原则，一个类应该有且只有一个改变的理由。 OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。 LSP，里氏替换原则，派生类要与其基类自相容。 DIP，依赖倒置原则，依赖于抽象而不是实现。 ISP，接口隔离原则，客户只要关注它们所需的接口。 包设计：六项原则。包是指一个二进制的可发布文件，如.jar文件，而非Java包。 包内聚性：三项，该把什么划分到包中： REP，重用发布等价原则，重用的粒度就是发布的粒度。 CCP，共同封闭原则，包中的所有类对于同一类性质的变化应该是共同封闭的。 CRP，共同重用原则，一个包中的所有类应该是共同重用的。 包耦合性：三项，系统中包结构优良
8、与否的评判标准。 ADP，无环依赖原则，在包的依赖关系图中不允许存在环。 SDP，稳定依赖原则，朝着稳定的方向进行依赖。 SAP，稳定抽象原则，包的抽象程度应该和其稳定程度一致。,五大原则：引入,初学阶段：一个独立的类就是属性+方法组成，在底层存储上也确实是这样的。 复杂项目：类与类之间的关系才是要探讨的内容。 类之间最主要的关系：依赖。 依赖肯定存在。其危害： 变化在某处发生时，影响会波及开来，造成很多修改工作。 依赖是和变化紧密联系在一起的。 变化不可避免，能做的就是处理好依赖关系，将变化造成的影响波及范围尽量减小。 记得： 一句话：“不变中不断在变” 一个问题：“如果需求发生变化了怎么办
9、？” 面向对象的设计中，如何通过很小的设计改变就可以应对需求的变化？ 解决方法：五大原则 并不相互孤立。彼此关联。互为加强或是基础。 违反其中的某一个，可能同时违反了其余的原则。,SRP：Single Responsibility Principle,单一职责原则： 对一个类而言，应该仅有一个引起它变化的原因。 高内聚性原则的引申，“职责”就是“变化的原因”。 要提高内聚性。 如果一个类承担的职责过多，那么这些职责就会相互依赖，一个职责的变化可能会影响另一个职责的履行。合理地进行类的职责/功能分配。 单一职责有两个含义： 避免相同的职责分散到不同的类中 避免一个类承担太多职责 单一职责有两个目
10、的： 减少类之间的耦合 如果减少类之间的耦合，当需求变化时，只修改一个类，从而也就隔离了变化；如果一个类有多个不同职责，它们耦合在一起，当一个职责发生变化时，可能会影响其他职责。 提高类的复用性 举例： 福特T型汽车-流水线 电脑的构成 modem的构成,SRP实践,一些简单的应该遵循的做法如下： 根据业务流程，把业务对象提炼出来。 如果业务流层的链路太复杂，就把这个业务对象分离为多个单一业务对象。 当业务链标准化后，对业务对象的内部情况做进一步处理。 把第一次标准化视为最高层抽象，第二次视为次高层抽象，以此类推，直到“恰如其分”的设计层次。 餐馆点餐的实现。,OCP：the Open Clo
11、sed Principle,个人认为是最高原则。 开闭原则： Closed for Modification; Open for Extension对变更关闭；对扩展开放。 或者：软件应该是可以扩展的，但是不可修改。 怎么实现？- 抽象功能、基于接口的开发。 基本思想是 Open(Open for extension)模块的行为必须是开放的、支持扩展的。 Closed(Closed for modification)在对模块的功能进行扩展时，不应该影响或大规模地影响已有的程序模块。 举例： 打印机,OCP实践,推荐实现思路： 设计中充分应用“抽象”和“封装”的思想。 在软件系统中找出各种可能的
12、“可变因素”，并将之封装起来； 一种可变性因素不应当散落在多个不同代码模块中，而应当被封装到一个对象中。 编程实现中应用面向接口的编程。 要求功能类实现接口，对象声明为接口类型。 需求发生变化时，提供该接口新的实现类，以适应变化。,LSP：Liskov Substitution Principle,里氏替换原则：Liskov于1987年提出 “Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”“继承必须确保父类所拥有的性质在子类中仍
13、然成立。” 或者：子类应当可以替换父类并出现在父类能够出现的任何地方，它们之间才具有is-a关系。 引入原因： 使用开闭原则完成依赖的限制，那么如何去度量继承关系的质量？-使用LSP Java中对LSP的支持： 继承并且覆盖父类方法的时候，子类中的方法的可见性必须等于或者大于父类中的方法的可见性；子类中的方法所抛出的异常只能是父类中对应方法所抛出的异常的子类。 “协变”(Covariant)：从Java5开始，子类中的方法的返回值也可以是对应的父类方法的返回值的子类。 题外话： DbC：1988年B. Meyer提出Design by Contract（契约式设计）。,DIP：Dependen
14、ce Inversion Principle,依赖倒置原则：实现开闭原则的主要机制 将依赖关系倒置为依赖接口。（要依赖于抽象,不要依赖于具体） 或者： 上层模块不应该依赖于下层模块，应该依赖于一个抽象。 抽象不能依赖于具体，具体应该要依赖于抽象。 几个近似概念： IOC：Inversion of Control DI：Dependence Inversion 举例： MVC-model2模式,DIP实践,如何实现DIP： 每个较高层次类都为它所需要的服务提出一个接口声明，较低层次类实现这个接口。 每个高层类都通过该抽象接口使用服务。 实践： 如何实现购物网站的商品展示？ 基于接口设计，依赖于接
15、口。,ISP：Interface Segregation Principle,接口隔离原则：和SRP有一定的重叠 Many client specific interfaces are better than one general purpose interface. 多个各客户端相关的接口优于一个通用接口。 引入原因： 胖接口（被污染的接口） 含有哑方法。 原因：期望在一个接口中完成所有的功能。 “一肩挑尽古今愁”？ ISP的主要观点： 一个类对另外一个类的依赖性应当是建立在最小的接口上的。 接口的实现类应该只呈现为单一职责的角色（遵守SRP原则）。 类不应该依赖它不需要的接口方法（功能）
16、。 Java的支持： Java允许接口的继承和多重实现。,ISP实践,ISP的原则： 客户端不应该被强迫实现一些他们不会使用的接口，应该把胖接口中的方法分组，然后用多个接口代替它，每个接口服务于一个子模块。 即：使用多个专门的接口不使用单个接口。 ISP的实现的2种方法： 使用委托（非.net委托delegate）分离接口 创建一个委托类，用此类去实现分离后的其它接口中的方法。 使用多重继承分离接口 将现有“胖”接口分成供不同客户程序调用的两个或多个接口，而需要实现多个接口的客户程序，则使用多重继承来实现。 使用较普遍，比较简单。,另外的一个原则,良性依赖原则 “不会在实际中造成危害的依赖关系，都是良性依赖。” XP,什么是设计,没有最优的设计，只有不完善的设计。,
