??@博主: 嘟嘟程序员铲屎官 ??:大家好，我是嘟嘟的程序员铲粪官，爱喵，爱开源，爱总结，爱分享技术Java领域的新星博主，如果你想和博主交朋友，关注博主，私下论博主（给我发信息，我会关注你），博主本人也喜欢解决问题，如果你有任何问题，你也可以私下谈论博主，希望和C站的朋友互相学习，互相进步。 ??：至于这个博客，我最近正在学习设计模式。本文主要学习设计模式的基本原则，并通过以下三个问题学习这一部分。如错误，请及时提出，以免弟弟误导孩子！
目录:
-
- 一.七大设计模式原则
-
- 1.单一职责原则(SRP)
- 2.接口隔离原则(ISP)
- 3.依靠倒转(倒置)的原则(DIP)
- 4.里氏替换原则(LSP)
- 5.开闭原则(OCP)
- 6.迪米特法则
- 7.合成复用原则(CARP)
- 二.汇总相关资源
设计模式（Design pattern）它是对大多数人都知道的重复使用、分类目的和代码设计经验的总结。
以前写项目的时候只需要大致了解一下，就开始疯狂输出，如下图所示 
然而，当我们准备编写一个非常大的项目时，会有很多问题。前辈们遇到了这些问题，总结了一下，写了一本葵花书，方便人们以后练习(少踩坑)。
提高代码的可重用性、代码的可读性和代码的可靠性。
根据设计模式的参考书<< Design Patterns - Elements of Reusable Object-Oriented Software>> 总共有 。
创建型模式（Creational Patterns）、 结构型模式（Structural Patterns）、 行为型模式（Behavioral Patterns）。 J2EE 设计模式。
设计模式原则实际上是程序员在编程时应遵循的原则，也是各种设计模式的基础。
一.七大设计模式原则
- 单一职责原则(SRP)
- 接口隔离原则(ISP)
- 依靠倒转(倒置)原则(DIP)
- 替氏替换原则(LSP)
- 开闭原则(OCP)
- 至少知道原则(迪米特法则)
- 合成复用原则(CARP)
1.单一职责原则(SRP)
对类来说，即一类应该只负责一项责任。例如，类A负责两种不同的责任 ：职责1，职责2。当职责1需要改变并改变A时，可能会导致职责2执行错误，因此类A的粒度需要分解为A1，A2
https://mp.weixin.qq.com/s?src=11×tamp=1643016089&ver=3578&signature=6KnseYLT8c8fZtngC7A7rjqn5PhiwEBd6-bvyTd6z4dVJTZyoave5TsoK3R9ItVYTPs8fXrDXh3VHMOl0fPe0AMGFsMU-dQ2CRsq-aFlFg2VCk-yNmydxB4b48Jt&new=1
一个类包括一些订单操作和一些用户操作。订单和用户是两个独立的业务领域模型。我们将两个不相关的功能放在同一类中，这违反了单一的责任原则。为了满足单一责任原则，我们需要将该类分为两类：订单类和用户类。
在社交产品中，我们使用以下内容 UserInfo 记录用户信息的类别。您认为，UserInfo 类设计符合单一职责原则吗？
public class UserInfo {
private long userId; private String username; private String email; private String telephone; private long createTime; private long lastLoginTime; private String avatarUrl;
private String provinceOfAddress; // 省
private String cityOfAddress; // 市
private String regionOfAddress; // 区
private String detailedAddress; // 详细地址
// ...省略其他属性和方法...
}
UserInfo 类包含的都是跟用户相关的信息，所有的属性和方法都隶属于用户这样一个业务模型，满足单一职责原则。 地址信息在 UserInfo 类中，所占的比重比较高，可以继续拆分成独立的 UserAddress 类，UserInfo 只保留除 Address 之外的其他信息，拆分之后的两个类的职责更加单一。
实际上，要从中做出选择，我们不能脱离具体的应用场景。 如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。但是，如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块，用户的地址信息还会用在电商物流中，那我们最好将地址信息从 UserInfo 中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）
如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）。公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。这个时候，我们就需要继续对 UserInfo 进行拆分，将跟身份认证相关的信息（比如，email、telephone 等）抽取成独立的类。
从刚刚这个例子，我们可以总结出，不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。
除此之外，从不同的业务层面去看待同一个类的设计，对类是否职责单一，也会有不同的认识。比如，例子中的 UserInfo 类。如果我们从“用户”这个业务层面来看，UserInfo 包含的信息都属于用户，满足职责单一原则。如果我们从更加细分的“用户展示信息”“地址信息”“登录认证信息”等等这些更细粒度的业务层面来看，那 UserInfo 就应该继续拆分。
综上所述，评价一个类的职责是否足够单一，我们并没有一个非常明确的、可以量化的标准，可以说，这是件非常主观、仁者见仁智者见智的事情。实际上，在真正的软件开发中，我们也没必要过于未雨绸缪，过度设计。所以，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构
- 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
- 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
- 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
- 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context之类的词语来命名，这就说明类的职责定义得可能不够清晰；
- 类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address信息，那就可以考虑将这几个属性和对应的方法拆分出来。
否
割韭韭-设计模式六大原则（1）：单一职责原则
2.接口隔离原则(ISP)
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
- 接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。如果一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专一的接口，使用多个专门的接口比使用单一的总接口要好。
- 接口的继承原则：如果一个接口A继承另一个接口B，则接口A相当于继承了接口B的方法，那么继承了接口B后的接口A也应该遵循上述原则：不应该包含用户不使用的方法。反之，则说明接口A被B给污染了，应该重新设计它们的关系。
接口I，该接口下有四个方法:method1~method5 类A依赖I接口实现:method1() 类B需要实现:method1(),method2(),method3() 类C依赖I接口实现:method2(),method3() 类D需要实现:method1(),method4(),method5()
-
A类将I接口作为参数，并通过I接口调用方法method1
-
B类实现I接口并重写I接口的所有方法
-
C类将I接口作为参数，并通过I接口调用方法method2,method3
-
D类实现I接口并重写I接口的所有方法
上面的代码虽然实现了需求,但是明显存在一些问题,B类和C类都实现了一些自己不需要实现的方法,如果I接口中的方法非常多(B类和C类不需要的方法)，那么B类C类就需要实现更多的方法,这显然不是我们想看见的,并且A类和C类是不符合接口隔离原则的,因为A类和C类所依赖的接口I并不是最小接口(I接口中存在A类和C类不需要的方法)
只需要将I接口进行拆分成I1,I2,I3接口,即I1接口包含method1()方法;I2接口包含method2()method3();I3接口包含method4(),method5()
- A类将I1接口作为参数，并通过I1接口调用方法method1
- B类实现I1,I2接口
- C类将I2接口作为参数，并通过I2接口调用方法method2,method3
- 类D实现I1,I3接口:
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
- 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
3.依赖倒转（倒置）原则(DIP)
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
- 依赖倒转（倒置）的中心思想是
面向接口编程。 - 依赖倒转原则是基于这样的设计理念 ：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类。
- 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展示细节的任务交给他们的实现类去完成。
母亲(Mother类)给自己的孩子讲解童话故事(Book类)。 Mother.java
Book.java
Test.java
运行效果: 上面的代码完成了需求,感觉没有任何问题,但是如果当妈妈讲解的故事不是童话故事而是神话故事,要完成这个需求就需要手动对Book里面getContent()方法的内容进行修改,这显然不是我们想要的，如何解决这个问题,看下面的代码。 Book.java(这里也可以采用有参构造方法对content进行初始化) Test.java 运行效果:
上面的代码很好的完成了需求,不管是讲童话故事,还是神话故事只需要对Book的内容进行设置即可,但是还是存在一个问题,如果妈妈不讲故事而是讲报纸,显然上面的代码就无法满足需求了，到这里我们应该明白Mother这个类的narrate()方法讲的内容不是具体的(不应该追求细节)而是抽象的,如何解决这个问题看下面的代码。
创建一个IReader接口（抽象类也可以） Book.java(Book类实现IReader接口,并重写该接口的方法) 创建Newspaper类,实现IReader接口,并重写该接口的方法 Test.java 运行效果:
总结:第一个需求Book类的内容是写死了的,如果要对Book内的内容进行修改,就需要手动进行修改,Book类和该内容是直接耦合的,但当用set访问器/有参构造方法对内容进行动态修改就避免了这种耦合，在Mother类与Book类之间也是耦合的,当Mother类讲的不是图书而是报纸的时候我们需要手动对Mother类中的代码进行修改,当我们将narrate()方法的参数改为接口后，就不需要关心这个问题了。
4.里氏替换原则(LSP)
- 里氏替换原则（Liskov Substitution Principle）在1988年，由麻省理工学院的一位姓里的女士提出的。
-
如果S是T的子类型，对于S类型的任意对象，如果将他们看作是T类型的对象，则对象的行为也理应与期望的行为一致。 - 在使用继承时，遵循里氏替换原则，
在子类中尽量不要重写父类的方法。 - 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过
聚合、组合、依赖来解决问题。
下面我们通过一个例子来理解里氏替换原则,该例子来源于:知乎-设计模式｜LSP(里氏替换)原则 需求(模拟人物通过各种类型的枪支进行射击):
- 编写一个AbstractGun抽象类,该类有一个抽象方法shoot()
- 编写AbstractGun抽象类的三个子类(Handgun,Rifle,MachineGun),并分别在子类中实现shoot()方法
- 编写一个Soldier类用来表示人物
- 编写一个Client类用来表示场景
- UML图如下
项目结构:
package principle_4;
public abstract class AbstractGun {
public abstract void shoot();
}
class MachineGun extends AbstractGun{
@Override
public void shoot() {
// TODO Auto-generated method stub
System.out.println("机枪射击~");
}
}
class Rifle extends AbstractGun{
@Override
public void shoot() {
// TODO Auto-generated method stub
System.out.println("步枪射击~");
}
}
class Handgun extends AbstractGun {
@Override
public void shoot() {
// TODO Auto-generated method stub
System.out.println("手枪射击~");
}
}
package principle_4;
public class Soldier {
private AbstractGun gun;
public void setGun(AbstractGun gun) {
this.gun = gun;
}
public void killEnemy() {
System.out.println("士兵开始杀人啦!");
this.gun.shoot();
}
}
package principle_4;
public class Client {
public static void main(String[] args) {
Soldier sanMao=new Soldier();
sanMao.setGun(new Handgun());
sanMao.killEnemy();
sanMao.setGun(new MachineGun());
sanMao.killEnemy();
sanMao.setGun(new Rifle());
sanMao.killEnemy();
}
}
运行效果:
理解里氏替换原则我们需要搞懂二个问题,1什么是替换,2什么是对象的行为理应与期望的行为一致,第一个问题什么是替换,替换其实就是多态的一种体现，上面的例子中Soldier类的setGun(AbstractGun gun)方法的参数为AbstractGun,在参数初始化的时候可以通过AbstractGun的子类进行初始化,即new Rifle(),new MachineGun(),和new Handgun()替代AbstractGun这就是替换。
第二个问题什么是对象的行为理应与期望的行为一致意思就是派生类的行为要和接口或基类保持一致,接口或基类的行为可以理解为一种契约,它的派生类都应当遵守这个契约,上面例子中在Soldier类的killEnemy()方法中，先是在控制台输出一个士兵开始杀人啦,然后再调用this.gun.shoot(),表明AbstractGun基类的shoot()方法其实就是杀人,它的子类的shoot()方法也应当遵守这个要求。 但是有一个问题当要新增一个子类ToyGun表示玩具枪,当该类继承AbstractGun时我们看看会发生什么?
运行效果:
显然上面的操作是不符合现实逻辑的,造成这个的原因是shoot()方法我们限制了该方法的功能就是杀人,但是AbstractGun基类的子类很多,并不是表示所有的枪都能够杀人,怎么解决呢? 解决方案:在Soldier类中的killEnemy()方法下判断该类是否为玩具枪 运行效果: 该方案虽然解决了我们提出的问题,但是当我们再增加一些无法杀人的枪械的时候，问题任然存在,解决方法不变的话,判断的语句会逐步增加，这个时候我们可以再编写一个AbstractToy抽象类该类被那些无法杀人的枪械继承,并且该抽象类还继承AbstractGun类，这样玩具枪(仿真枪)也可以使用真枪的一些属性。 UML图如下:
创建AbstractToy抽象类并继承AbstractGun AbstractGun.java中ToyGun类继承AbstractToy Soldier.java中修改判断条件 Client.java
运行效果: 在上面的例子中我们不断修改代码，其实就是为了遵守里氏替换原则。
需求():
- 编写一个ArrayList 的子类CustomList,并且在该类中重写get(int index)方法
- 编写一个ListTest用于测试
CustomList.java ListTest.java 运行效果:
由于CustomList类重写了ArrayList类中的get(int index),改变了基类的get(int index)的行为,导致违背了基类get(int index)的契约, 即违反了里氏替换原则。
需求二()
- 当获取集合的元素的下标越界的时候，输出null
在CustomList中 在ListTest中
再次运行ListTest:
在上面的例子中,虽然通过重写的方式完成了需求,但是该方式违背了里氏替换原则,当输入index大于当前list的size时，返回null，而不抛出IndexOutOfBoundsException, 因为List接口关于get方法的描述，当index超出范围时抛出IndexOutOfBoundsException，所以改变了基类方法的语义，即违反了里氏替换原则。
我们可以这样做:
5.开闭原则(OCP)
- 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
-
一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（对使用方）。用抽象构建框架，用实现扩展细节。 - 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
- 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
下面通过例子进行学习:
- 编写一个GraphicEditor用于绘图的类
- 编写一个Shape绘图的基类
- 编写一个Shape的子类Rectangle表示绘制矩形
- 编写一个Shape的子类Circle表示绘制圆形
UML图如下：
项目结构如下: GraphicEditor.java
package principle_5;
/** * 这是一个用于绘图的类（使用方） */
public class GraphicEditor {
/** * 接收Shape对象，然后根据type，来绘制不同的图形 * @param shape */
public void drawShape(Shape shape) {
if (shape.m_type == 1) {
drawRectangle(shape);
} else if (shape.m_type == 2) {
drawCircle(shape);
}
}
/** * 绘制圆形 * @param shape */
private void drawCircle(Shape shape) {
System.out.println("绘制圆形");
}
/** * 绘制矩形 * @param shape */
private void drawRectangle(Shape shape) {
System.out.println("绘制矩形");
}
}
/** * Shape类，基类 */
class Shape {
int m_type;
}
class Rectangle extends Shape {
Rectangle() {
super.m_type = 1;
}
}
class Circle extends Shape {
Circle() {
super.m_type = 2;
}
}
OcpTest.java
package principle_5;
public class OcpTest {
public static void main(String[] args) {
// 使用看看存在的问题
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
}
}
运行效果: 上面的代码很好的完成了需求,但是如果要画一个三角形我们怎么办呢?
- 需要新增一个画三角形的类Triangle
- 在GraphicEditor()中编写如下代码
在OcpTest中
运行效果:
上面这种方式虽然解决了问题,但是还是存在一些弊端:
- 我们对使用方(GraphicEditor)的代码进行了修改,违反了设计模式的ocp原则
- 当我们每新增加一个图形后就要再一次对GraphicEditor中多处代码进行修改
把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承Shape，并实现draw方法即可，使用方的代码就不需要修改,满足了开闭原则。 项目结构: GraphicEditor.java
package principle_5_1;
/** * 这是一个用于绘图的类（使用方） */
public class GraphicEditor {
/** * 接收Shape对象，调用draw方法 * @param shape */
public void drawShape(Shape shape) {
shape.draw();
}
}
/** * Shape类，基类 */
abstract class Shape {
int m_type;
/** * 抽象方法 */
public abstract void draw();
}
class Rectangle extends Shape {
Rectangle() {
super.m_type = 1;
}
@Override
public void draw() {
System.out.println("绘制矩形");
}
}
class Circle extends Shape {
Circle() {
super.m_type = 2;
}
@Override
public void draw() {
System.out.println("绘制圆形");
}
}
/** * 新增画三角形 */
class Triangle extends Shape {
Triangle() {
super.m_type = 3;
}
@Override
public void draw() {
System.out.println("绘制三角形");
}
}
OcpTest.java
运行效果: 这种方式就无需再对GraphicEditor中的代码进行修改,如果要新增一个图形，只需要创建一个图形类去继承Shape抽象类,并重写draw()方法即可。
实现方式如下图: OcpTest.java中 运行效果: https://mp.weixin.qq.com/s?src=11×tamp=1643554761&ver=3590&signature=qQTfcTroHTN8wzx6nEDelGtbukilB3Qt*cLFbvaxM5tzlIBbotsH2HoMxLXwD6mt6uHyjhNljjSiJkSg4Py8ZmZsYOcc2m2un7IuFRCtwqyX1y6ikvuFPY8kHJQe-F8n&new=1
6.迪米特法则
- 一个对象应该对其他对象保持最少的了解。
- 类与类关系越密切，耦合度越大。
-
迪米特法则（Demeter Principle）又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。 - 迪米特法则还有个简单的定义 ：。
-
每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联组合、聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
通过一个实例来学习:
- 有一个学校，下属有各个学院和总部，现要求打印出学校总部员工ID和学院员工的id
- 编写一个Demeter1类客服端用于打印信息
- 编写一个Employee类表示学校总部员工
- 编写一个CollegeEmployee 类用于表示学院的员工
- 编写一个CollegeManager 类用于管理学院员工
- 编写一个SchoolManager 类用于管理学校
项目结构如下: CollegeEmployee.java CollegeManager.java Employee.java SchoolManager.java
package prnciple_6;
import java.util.ArrayList;
import java.util.List;
public class SchoolManager {
/** * 返回学校总部的员工 * * @return */
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<>();
// 这里我们增加了5个员工到list
for (int i = 0; i < 5; i++) {
Employee employee = new Employee();
employee.setId("学校总部员工 id = " + i);
list.add(employee);
}
return list;
}
/** * 该方法完成输出学校总部和学院员工信息 （id） * * @param collegeManager */
void printAllEmployee(CollegeManager collegeManager) {
// 分析问题
// 1. 这里的 CollegeEmployee 不是 SchoolManageer的直接朋友
// 2. CollegeEmployee 是以局部变量方式出现在 SchoolManager
// 3. 违反了 迪米特法则
// 获取到学院员工
List<CollegeEmployee> allEmployee = collegeManager.getAllEmployee();
System.out.println("-------------学院员工-------------");
for (CollegeEmployee collegeEmployee : allEmployee) {
System.out.println(collegeEmployee.getId());
}
// 获取到学院总部员工
List<Employee> employee = this.getAllEmployee();
System.out.println("-----------学校总部员工-------------");
for (Employee employee1 : employee) {
System.out.println(employee1.getId());
}
}
}
Demeter1.java 运行效果:
- CollegeEmployee是CollegeManager的直接朋友
- Employee是SchoolManager的直接朋友
- CollegeEmployee并不是SchoolManager的直接朋友
CollegeEmployee在SchoolManager中以局部变量的方式出现，所以CollegeEmployee不是SchoolManager的直接朋友，CollegeEmployee增加了和SchoolManager的耦合性,不满足迪米特法则。
红框框里面的代码是打印学院员工的信息,这个的实现细节应该放在CollegeManager中去实现,在SchoolManager中无需关心怎么实现的,只需要通过调用CollegeManager中的方法去完成获取学院员工信息即可。
- 在CollegeManager中增加printCollegeEmployee方法,并将红框框代码移到此处,并将collegeManager修改为this
- SchoolManager中printAllEmployee()里通过CollegeManager调用printCollegeEmployee()打印所有学院员工信息。
- 迪米特法则的核心是降低类之间的耦合
- 但是注意 ：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间（对象间）耦合关系，并不是要求完全没有依赖关系。
7.合成复用原则(CARP)
合成复用原则（Composite/Aggregate Reuse Principle，CARP）是指尽量使用对象组合（has-a）/聚合（contanis-a）而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。
- 继承复用
- 合成复用
优点:简单,易实现 缺点:
- 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
- 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
- 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点。
- 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
- 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
- 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。
- 类B需要使用类A的operation1(),operation2()和operation()三个方法
- 编写一个A类,该类下包含三个方法operation1(),operation2()和operation()
- 编写一个A类的子类B
- 编写一个BTest类用于测试
UML类图如下:
项目结构如下: A.class
B.class BTest.java
运行效果:
上面的方式虽然完成了需求但是该方式是通过继承方式实现,存在许多继承复用的缺点。
B.java中的代码: BTest.java中的代码 运行效果: 在B.java中
BTest.java
运行效果: B.java BTest.java 运行效果: 或者直接在B类中对成员变量进行初始化 B.java BTest.java 运行效果:
上面的几种方式耦合性分别为:依赖<聚合<组合<继承
合成复用原则——面向对象设计原则 谈一谈自己对依赖、关联、聚合和组合之间区别的理解
二.相关资源汇总
视频学习链接: 尚硅谷Java设计模式（图解+框架源码剖析） 相关电子图书下载: 23种设计模式整理（很全）.pdf 密码:yyds Head First 设计模式 密码:gkn5 (推荐) 23 种设计模式知识要点 密码:w55h 大话