rhb_blog

rao的博客

0%

java-面向对象思想

发表于 更新于 分类于 ，

面向对象思想

类图

泛化关系（Generalization）

用来描述继承关系，在 Java 中使用 extends 关键字。

实现关系 (Realization)

用来实现一个接口，在 Java 中使用 implements 关键字。

关联关系 (Association)

表示不同类对象之间有关联，这是一种静态关系，与运行过程的状态无关，在最开始就可以确定。因此也可以用 1 对 1、多对 1、多对多这种关联关系来表示。比如学生和学校就是一种关联关系，一个学校可以有很多学生，但是一个学生只属于一个学校，因此这是一种多对一的关系，在运行开始之前就可以确定。

【代码表现】：成员变量

聚合关系 (Aggregation)

表示整体由部分组成，但是整体和部分不是强依赖的，整体不存在了部分还是会存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

【代码表现】：成员变量

组合关系 (Composition)

和聚合不同，组合中整体和部分是强依赖的，整体不存在了部分也不存在了。比如公司和部门，公司没了部门就不存在了。但是公司和员工就属于聚合关系了，因为公司没了员工还在。

组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期

【代码表现】：成员变量

依赖关系 (Dependency)

和关联关系不同的是，依赖关系是在运行过程中起作用的。A 类和 B 类是依赖关系主要有三种形式：

  • A 类是 B 类方法的局部变量；
  • A 类是 B 类方法的参数；
  • A 类向 B 类发送消息，从而影响 B 类发生变化。

【代码表现】：局部变量、方法的参数或者对静态方法的调用

各种关系的强弱顺序

泛化=实现>组合>聚合>关联>依赖

面向对象的六大原则

1、单一职责原则SRP

面向对象的六大原则就一个类而言，应该仅有一个引起它变化的原因。

简单的说就是：一个类中应该是一组相关性很高的函数、数据的封装。两个不一样的功能不应该放在一个类中。

这个原则没有具体的划分界限，需要根据个人经验，具体业务逻辑而定。这也是优化代码的第一步。试想一下，如果所有的功能写在一个类里，那么这个类会越来越大，越来越复杂，越不易修改维护。那么根据功能，各自独立拆分出来，岂不是逻辑会清晰些。

2、开闭原则OCP

定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。当软件需要变化时，我们尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现（可能引入的代码会破坏原有系统）。

3、里氏替换原则LSP

定义：所有引用父类的地方，必须能使用子类的对象。简单地说就是将父类替换为他的子类是不会出现问题，反之，未必可以。

那么里氏替换原则就是依赖于面向对象语言的继承与多态。核心原理是抽象。

这里列举一下继承的优缺点：
优点：
（1）代码重用，减少创建类的成本，每个子类都拥有父类的方法与属性。
（2）子类与父类基本相似，但与父类又有所区别。
（3）提高代码的可扩展性。
缺点：
（1）继承是侵入性的，只要继承就必须拥有父类所有的属性与方法。
（2）可能造成子类代码冗余、灵活性降低。

开闭原则和里氏替换原则是生死相依的、不离不弃的。他们都强调了抽象这一重要的特性。

看着定义很是抽象，但是通俗的理解就是由子类实例化的父类引用，在使用这个引用时，感觉就像是使用了父类一样。一个简单的例子：

1
2
3
4
5
6
7
8
9
public class T{
  private class A{...}
  class B extends A{...}
  public static void main(String[] args){
    A a = new B();
    // 类型是A，但实际是B类型实例化的，就是依赖多态
    a.method();
  }
}

4、依赖倒置原则DIP

定义：指代一种特定的解耦方式，使得高层次的模块不依赖于低层次的模块的实现细节的目的。他有一下几个关键点：
（1）高层模块不依赖于低层模块，应该都依赖其抽象。
（2）抽象不依赖细节。
（3）细节应依赖抽象。

解释：在Java中，抽象就是指接口或者抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的就是细节，也就是可以加上一个关键字new产生的对象。高层模块就是调用端，底层模块就是具体实现类。

依赖倒置原则在Java中的表现就是：模块间通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系是通过接口或者抽象类产生的。如果类与类直接依赖细节，那么就会直接耦合，那么当修改时，就会同时修改依赖者代码，这样限制了可扩展性。

5、接口隔离原则ISP

定义：类间的依赖关系应该建立在最小的接口上，将庞大、臃肿的接口拆分成更小的、更具体的接口。目的是系统的解耦，从而更容易重构、更改和重新部署。

6、迪米特原则LOD

定义：一个类应该对自己需要耦合或者调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或依赖者只需知道他需要的方法，其他可以一概不管。这样使得系统具有更低的耦合与更好的可扩展性。