目录
1.什么是设计模式?
懂了设计模式,你就懂了面向对象分析和设计(OOA/D)的精要
通俗来讲,设计模式就是对于特定问题的一套通用解决方案
设计模式是解决稳定中有变化的问题
每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心,这样,你就能一次一次地使用该方案,而不必做重复的劳动。
- 面向对象
- 可复用
- 这里的复用指的是二进制级别的复用,即源代码编译后,不需要再去改动再编译它而直接使用
- 重复使用某个片段的代码不是设计模式中的复用
1.1 面向对象
(1)面向对象背后的两种思维:
底层思维:
- 语言构造
- 编译转换
- 内存模型
- 运行时机制
抽象思维:
- 面向对象
- 组件封装
- 设计模式
- 架构模式
(2)深入理解面向对象
向下:深入理解三大面向对象机制
- 封装,隐藏内部实现
- 继承,复用现有代码
- 多态,改写对象行为
向上:深刻把握面向对象机制所带来的抽象意义,理解如何使用这些机制来表达现实世界,掌握什么是“好的面向对象设计”
1.2 软件设计复杂的根本原因——变化
- 客户需求的变化
- 技术平台的变化
- 开发团队的变化
- 市场环境的变化
1.3 人类解决复杂性的通用方法
(1)分解
- 人们面对复杂性有一个常见的做法:即分而治之,将大问题分解为多个小问题,将复杂问题分解为多个简单问题
(2)抽象
- 更高层次来讲,人们处理复杂性有一个通用的技术,即抽象
- 由于不能掌握全部的复杂对象,我们选择忽视它的非本质细节,而去处理泛化和理想化了的对象模型
1.4 从抽象层面来理解面向对象
变化是复用的天敌,面向对象设计最大的优势在于:抵御变化
(1)理解隔离变化
- 从宏观层面来看,面向对象的构建方式更能适应软件的变化能将变化所带来的影响力减为最小
(2)各司其职
- 从微观层面来看,面向对象的方式更强调各个类的“责任”
- 由于需求变化导致的新增类型不应该影响原来类型的实现——是所谓各负其责(多态的调用实现责任的分派)
(3)对象是什么?
- 从语言实现层面来说,对象封装了代码和数据
- 从规格层面讲,对象是一系列可被使用的公共接口
- 从概念层面,对象是某种拥有责任的抽象
2.什么时候用得到设计模式
设计模式在软件中的哪里?
面向对象(oo)===>功能模块(设计模式+算法(+数据结构))===>框架(使用到多种设计模式)===>架构(服务器集群)
设计模式的目的:
使用设计模式是为了让我们的软件具有以下特点:
- 1.可复用性
- 相同功能的代码不用多次编写
- 2.可读性
- 编程的规范性,便于其他程序员的阅读和理解
- 3.可扩展性
- 当需要增加新的功能时,非常的方便,也叫可维护性
- 4.可靠性
- 当我们增加新的功能后,对原有的功能没有任何影响
- 5.使程序具有“高内聚,低耦合”的特性
- 每个模块内部非常紧密,模块与模块之间或功能与功能之间依赖性很低,如A模块出现错误尽量在A模块爆出来,不要把错误带到B模块去
3.设计模式的七大原则
设计模式的原则是程序员在编程时应该遵守的原则,也是设计模式为什么这样去设计的依据
3.1 单一职责原则
(1)基本介绍
- 对类来说的,即一个类应该只负责一项职责,
- 如类A负责两个不同的职责:职责1,职责2,当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2
(2)案例分析
示例1:
SingleResponibility01.java
package cn.cqu.principles.singleResponsibility;
public class SingleResponsibility01 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("摩托车");
vehicle.run("汽车");
vehicle.run("飞机");
}
}
/**
* 交通工具类
*/
class Vehicle{
public void run(String vehicle)
{
System.out.println(vehicle+"在公路上运行。。。");
}
}

分析:
- 1.在示例1中的run方法中违背了单一职责原则
- 2.解决方案非常简单,按照交通工具运行方法的不同,分解成不同的类即可
示例2:
SingleResponibility02.java
package cn.cqu.principles.singleResponsibility;
public class SingleReponsibility02 {
public static void main(String[] args) {
RoadVehicle roadVehicle = new RoadVehicle();
roadVehicle.run("摩托车");
roadVehicle.run("汽车");
AirVehicle airVehicle = new AirVehicle();
airVehicle.run("飞机");
}
}
/**
* 路上跑的交通工具类
*/
class RoadVehicle{
public void run(String vehicle)
{
System.out.println(vehicle+"在公路上运行。。。");
}
}
/**
* 空中运行的交通工具类
*/
class AirVehicle{
public void run(String vehicle)
{
System.out.println(vehicle+"在天空上运行。。。");
}
}
/**
* 水中运行的交通工具类
*/
class WaterVehicle{
public void run(String vehicle)
{
System.out.println(vehicle+"在水中运行。。。");
}
}

分析:
- 1.遵守了单一职责原则
- 2.但是这样做的改动很大,即将类分解,同时修改客户端
- 3.改进:直接修改Vehicle类,改动的代码比较少
示例3:
SingleResponibility03.java
package cn.cqu.principles.singleResponsibility;
public class SingleReponsibility03 {
public static void main(String[] args) {
Vehicle2 vehicle2 = new Vehicle2();
vehicle2.run("汽车");
vehicle2.runAir("飞机");
vehicle2.runWater("轮船");
}
}
/**
* 交通工具类
*/
class Vehicle2{
public void run(String vehicle)
{
System.out.println(vehicle+"在公路上运行。。。");
}
public void runAir(String vehicle)
{
System.out.println(vehicle+"在天空中运行。。。");
}
public void runWater(String vehicle)
{
System.out.println(vehicle+"在水中运行。。。");
}
}

分析:
- 1.这种方法没有对原来的类做大的修改,只是增加了方法
- 2.这个虽然没有在类这个级别上遵守单一职责原则,但是在方法级别上,遵守了单一职责原则
(3)单一职责原则的注意事项和细节
- 1.降低类的复杂度,一个类只负责一项职责
- 2.提高类的可读性,可维护性
- 3.降低变更引起的风险,比如说方式2中我们要变更其中一种交通方式,只需要变更一个类中的代码
- 4.通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级别违反单一职责原则;只有类中方法数量足够少,可以在方法级别保持单一职责原则
3.2 接口隔离原则
(1)基本介绍
- 客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上
(2)案例分析
示例1:
示例描述:
- 类A通过接口Interface1依赖于(使用)类B,但是A中只会使用到接口的1,2,3个方法
- 类C通过接口Interface1依赖于(使用)类D,但是C中只会使用到接口的1,4,5个方法
UML类图:

代码实现:
package cn.cqu.principles.segregation;
import javax.sound.midi.Soundbank;
public class Segregation1 {
public static void main(String[] args) {
}
}
//接口
interface Interface1{
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
class B implements Interface1{
@Override
public void operation1() {
System.out.println("B实现了operation1");
}
@Override
public void operation2() {
System.out.println("B实现了operation2");
}
@Override
public void operation3() {
System.out.println("B实现了operation3");
}
@Override
public void operation4() {
System.out.println("B实现了operation4");
}
@Override
public void operation5() {
System.out.println("B实现了operation5");
}
}
class D implements Interface1{
@Override
public void operation1() {
System.out.println("D实现了operation1");
}
@Override
public void operation2() {
System.out.println("D实现了operation2");
}
@Override
public void operation3() {
System.out.println("D实现了operation3");
}
@Override
public void operation4() {
System.out.println("D实现了operation4");
}
@Override
public void operation5() {
System.out.println("D实现了operation5");
}
}
class A{
public void depend1(Interface1 i)
{
i.operation1();
}
public void depend2(Interface1 i)
{
i.operation2();
}
public void depend3(Interface1 i)
{
i.operation3();
}
}
class C{
public void depend1(Interface1 i)
{
i.operation1();
}
public void depend2(Interface1 i)
{
i.operation4();
}
public void depend3(Interface1 i)
{
i.operation5();
}
}
分析:
- B中的4,5方法白写了,D中的2,3方法白写了,因为都不会被用到
- 即此种情况下,Interface1对于类A和类C来说都不是最小接口,类B和类D必须实现不会被类A和类C用到的方法,即不符合接口隔离原则
示例2:
示例描述:
- 将接口Interface1拆分为独立的几个接口,类A和类C分别与它们需要的接口建立依赖关系,也就是采用接口隔离原则
UML类图:

代码实现:
package cn.cqu.principles.segregation;
public class Segregation2 {
public static void main(String[] args) {
A a = new A();
B b = new B();
a.depend1(b);//A类通过接口去依赖于B类
a.depend2(b);
a.depend3(b);
C c = new C();
D d = new D();
c.depend1(d);//C类通过接口去依赖于D类
c.depend4(d);
c.depend5(d);
}
}
//接口1
interface Interface1{
void operation1();
}
//接口2
interface Interface2{
void operation2();
void operation3();
}
//接口3
interface Interface3{
void operation4();
void operation5();
}
class B implements Interface1,Interface2{
@Override
public void operation1() {
System.out.println("B实现了operation1");
}
@Override
public void operation2() {
System.out.println("B实现了operation2");
}
@Override
public void operation3() {
System.out.println("B实现了operation3");
}
}
class D implements Interface1,Interface3{
@Override
public void operation1() {
System.out.println("D实现了operation1");
}
@Override
public void operation4() {
System.out.println("D实现了operation4");
}
@Override
public void operation5() {
System.out.println("D实现了operation5");
}
}
class A{
public void depend1(Interface1 i)
{
i.operation1();
}
public void depend2(Interface2 i)
{
i.operation2();
}
public void depend3(Interface2 i)
{
i.operation3();
}
}
class C{
public void depend1(Interface1 i)
{
i.operation1();
}
public void depend4(Interface3 i)
{
i.operation4();
}
public void depend5(Interface3 i)
{
i.operation5();
}
}

总结:一个类通过接口去依赖于另一个类,我们希望我们所依赖的接口是最小的,用不到的方法通过拆分接口的方式来进行隔离
3.3 依赖倒转原则
(1)基本介绍
- 1.高层模块不应该依赖低层模块(变化),二者都应该依赖于其抽象(稳定)
- 2.抽象(稳定)不应该依赖实现细节(变化),实现细节应该依赖抽象
- 3.依赖倒转的中心思想是面向接口编程
- 4.依赖倒转原则是基于这样的理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中,抽象指的是接口或抽象类,细节就是具体的实现类
- 5.不将变量类型声明为某个特定的具体类型(这里指的是我们自己写的业务类,不包括语言本身提供的类型String,Integer等等这些),而是声明为某个接口,客户程序无需获知对象的具体类型,只需要知道对象所具有的接口
- 6.使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成
(2)案例分析
有一个Person类,需要去接收消息
示例1:
package cn.cqu.principles.inversion;
public class DependencyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email{
public String getInfo(){
return "电子邮件信息:hello,world";
}
}
//完成Person接收消息的功能
class Person{
public void receive(Email email){
System.out.println(email.getInfo());
}
}

分析:
- 1.这种实现方式比较简单,比较容易想到
- 2.如果我们获取的对象是微信、短信等等的信息,则需要新增类,同时Person类要增加相应的接收方法
示例2:
上述问题的解决思路:引入抽象的接口IReceiver,表示接收者,这样Person类与接口发生依赖
因为Email、WeiXin等等属于接收的范围,他们实现各自实现IReceiver接口就行,这样就符合依赖倒转原则
代码实现:
package cn.cqu.principles.inversion;
public class DependencyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
person.receive(new WeiXin());
}
}
//定义接口
interface IReceiver{
public String getInfo();
}
//Email
class Email implements IReceiver{
public String getInfo(){
return "电子邮件信息:hello,world";
}
}
//增加WeiXin,不需要改动Person类
class WeiXin implements IReceiver{
public String getInfo(){
return "微信消息:hello,world";
}
}
//完成Person接收消息的功能
class Person{
public void receive(IReceiver receiver){
System.out.println(receiver.getInfo());
}
}

依赖关系的三种传递方式:
方式1:通过接口传递依赖
package cn.cqu.principles.inversion;
public class DependencyPass {
public static void main(String[] args) {
ChangHong changHong = new ChangHong();
//通过接口传递依赖
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.open(changHong);
}
}
interface ITV { //ITV接口
void play();
}
class ChangHong implements ITV {
@Override
public void play() {
// TODO Auto-generated method stub
System.out.println("长虹电视机,打开");
}
}
//方式1: 通过接口传递实现依赖
//开关的接口
interface IOpenAndClose {
void open(ITV tv); //抽象方法,接收接口
}
// 实现接口
class OpenAndClose implements IOpenAndClose{
public void open(ITV tv){
tv.play();
}
}

方式2:通过构造方法传递依赖
package cn.cqu.principles.inversion;
public class DependencyPass {
public static void main(String[] args) {
ChangHong changHong = new ChangHong();
//通过构造方法传递依赖
OpenAndClose openAndClose = new OpenAndClose(changHong);
openAndClose.open();
}
}
interface ITV { //ITV接口
void play();
}
class ChangHong implements ITV {
@Override
public void play() {
// TODO Auto-generated method stub
System.out.println("长虹电视机,打开");
}
}
//方式2: 通过构造方法依赖传递
interface IOpenAndClose {
void open(); //抽象方法
}
class OpenAndClose implements IOpenAndClose{
public ITV tv; //成员
public OpenAndClose(ITV tv){ //构造器
this.tv = tv;
}
public void open(){
this.tv.play();
}
}

方式3:通过set方法传递依赖
package cn.cqu.principles.inversion;
public class DependencyPass {
public static void main(String[] args) {
ChangHong changHong = new ChangHong();
//通过setter方法进行依赖传递
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();
}
}
interface ITV { //ITV接口
void play();
}
class ChangHong implements ITV {
@Override
public void play() {
// TODO Auto-generated method stub
System.out.println("长虹电视机,打开");
}
}
// 方式3 , 通过setter方法传递
interface IOpenAndClose {
void open(); // 抽象方法
void setTv(ITV tv);
}
class OpenAndClose implements IOpenAndClose {
private ITV tv;
public void setTv(ITV tv) {
this.tv = tv;
}
public void open() {
this.tv.play();
}
}

(3)依赖倒转原则的注意事项和细节
- 1.低层模块尽量都要有抽象类或接口,或者两者都有,程序的稳定性更好
- 2.变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利于程序扩展和优化
- 3.继承时遵循里氏代换原则
3.4 里氏代换原则
OO中的继承性的思考和说明
- 1.继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然它不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏。
- 2.继承在程序设计带来便利的同时,也带来了弊端,比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有子类,并且父类修改后,所有涉及到的子类的功能都有可能产生故障
- 于是在编程中,如何正确的使用继承?===>里氏代换原则
(1)基本介绍
- 1.所有引用基类的地方必须能透明地使用其子类的对象,即子类必须能够替换它们的基类(is-a)
- 2.在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
- 3.里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,我们迫不得已需要重写父类的方法时,在适当的情况下,可以通过聚合,组合,依赖来解决问题
(2)案例分析
示例1:
package cn.cqu.principles.Liskov;
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3="+a.func1(11,3));
System.out.println("1-8="+a.func1(1,8));
System.out.println("----------");
B b = new B();
System.out.println("11-3="+b.func1(11,3));
System.out.println("1-8="+b.func1(1,8));
System.out.println("11+3+9="+b.func2(11,3));
}
}
class A{
//返回两个数的差
public int func1(int num1,int num2)
{
return num1 - num2;
}
}
class B extends A{
//返回两个数的差
public int func1(int a,int b)
{
return a + b;
}
public int func2(int a,int b)
{
return func1(a,b)+9;
}
}

分析:
- 我们发现原来运行正常的相减功能发生了错误,原因就是类B无意中重写了父类的方法,造成原有功能出现错误。实际编程中,我们常常会通过重写父类的方法完成新的功能,这样写起来虽然简单,但整个继承体系的复用性会比较差,特别是运行多态比较频繁的时候
通常的解决办法:
- 原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖,聚合,组合等关系代替
示例2:

package cn.cqu.principles.Liskov;
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println("11-3="+a.func1(11,3));
System.out.println("1-8="+a.func1(1,8));
System.out.println("----------");
B b = new B();
//因为B类不再继承A类,因此,调用者就不会再认为func1是求减法
//调用完成的功能很明确
//System.out.println("11-3="+b.func1(11,3));
System.out.println("11+3="+b.func1(11,3));
//System.out.println("1-8="+b.func1(1,8));
System.out.println("1+8="+b.func1(1,8));
System.out.println("11+3+9="+b.func2(11,3));
//使用组合仍然可以使用A类相关方法
System.out.println("11-3="+b.func3(11,3));
}
}
class Base{
//把更加基础的方法和成员写到Base类中
}
class A extends Base{
//返回两个数的差
public int func1(int num1,int num2)
{
return num1 - num2;
}
}
class B extends Base{
//如果B类中需要使用到A类中的方法,使用组合关系
private A a = new A();
//返回两个数的差
public int func1(int a,int b)
{
return a + b;
}
public int func2(int a,int b)
{
return func1(a,b)+9;
}
//我们仍然使用A的方法
public int func3(int a,int b)
{
return this.a.func1(a,b);
}
}

3.5 开放封闭原则
(1)基本介绍
- 一个软件实体,如类、模块和函数应该对扩展开放(提供方),对修改封闭(使用方),用抽象构建框架,用实现扩展细节
- 当软件需求发生变化的时候,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化
- 编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则,开闭原则是编程的核心
(2)案例分析
示例1:
package cn.cqu.principles.ocp;
public class OCP {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
//新增的代码
graphicEditor.drawShape(new Triangle());
}
}
//这是一个用于绘图的类
class GraphicEditor{
//接收Shape对象,然后根据type,来绘制不同的图形
public void drawShape(Shape s)
{
if(s.m_type==1)
{
drawRectangle(s);
}
else if(s.m_type==2){
drawCircle(s);
}
//新增的代码
else if(s.m_type==3)
{
drawTriangle(s);
}
}
//使用方
public void drawRectangle(Shape s)
{
System.out.println("绘制矩形");
}
public void drawCircle(Shape s)
{
System.out.println("绘制圆形");
}
//新增的代码
public void drawTriangle(Shape s)
{
System.out.println("绘制三角形");
}
}
//基类
class Shape
{
int m_type;
}
class Rectangle extends Shape{
Rectangle(){
m_type=1;
}
}
class Circle extends Shape{
Circle(){
m_type=2;
}
}
//三角形(提供方)
class Triangle extends Shape{
Triangle(){
m_type=3;
}
}

分析:
- 在增加绘制三角形的类的时候,我们既添加了提供方的类,还修改了使用方的类中的方法,违背了开放封闭原则
示例2:
改进上述代码思路:
把创建Shape类做成抽象类,并提供提供一个抽象的draw方法,让子类去实现即可,这样我们又新的图形种类时,让它继承Shape即可,并实现draw方法
package cn.cqu.principles.ocp;
public class OCP {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Triangle());
graphicEditor.drawShape(new OtherGraphic());
}
}
//这是一个用于绘图的类
class GraphicEditor{
//接收Shape对象,然后根据type,来绘制不同的图形
public void drawShape(Shape s)
{
s.draw();
}
}
//基类
abstract class Shape
{
public abstract void draw();
}
class Rectangle extends Shape{
@Override
public void draw() {
System.out.println("绘制矩形");
}
}
class Circle extends Shape{
@Override
public void draw() {
System.out.println("绘制圆形");
}
}
//三角形(提供方)
class Triangle extends Shape{
@Override
public void draw() {
System.out.println("绘制三角形");
}
}
//新增代码
//其他图形类(提供方扩展类)
class OtherGraphic extends Shape{
@Override
public void draw() {
System.out.println("绘制其他图形");
}
}

对提供方新增类,进行扩展,对使用方不做任何修改
3.6 迪米特法则
又叫“最少知道原则”
(1)基本介绍
- 一个对象应该对其他对象保持最少的了解
- 类与类关系越密切,耦合度越大
- 即一个类对自己依赖的类知道的越少越好,也就是说,对于被依赖的类,不管多么复杂,都尽量将逻辑封装在类的内部,对外除了提供的public方法,不对外泄露任何信息
- 迪米特法则还有个更简单的定义:只与直接的朋友通信
- 朋友关系:每个对象都与其他对象有耦合关系,只要两个对象之间有耦合关系,就说这两个对象是朋友关系
- 耦合的方式很多,有依赖、关联、组合、聚合等等
- 直接的朋友:其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友
- 出现在局部变量中的类不是直接的朋友
- 也就是说,陌生的类最好不要以局部变量的形式出现在类的内部
(2)案例分析
示例需求:
有一个学校,下属有各个学院和总部,现要求打印出学校总部员工id和学院员工id
示例1:
package cn.cqu.principles.demeter;
import java.util.ArrayList;
import java.util.List;
//客户端
public class Demeter1 {
public static void main(String[] args) {
//创建了一个 SchoolManager 对象
SchoolManager schoolManager = new SchoolManager();
//输出学院的员工id 和 学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工类
class Employee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//学院的员工类
class CollegeEmployee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//管理学院员工的管理类
class CollegeManager {
//返回学院的所有员工
public List<CollegeEmployee> getAllEmployee() {
List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id= " + i);
list.add(emp);
}
return list;
}
}
//学校管理类
//分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
//CollegeEmployee 不是 直接朋友 而是一个陌生类,这样违背了 迪米特法则
class SchoolManager {
//返回学校总部的员工
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
Employee emp = new Employee();
emp.setId("学校总部员工id= " + i);
list.add(emp);
}
return list;
}
//该方法完成输出学校总部和学院员工信息(id)
void printAllEmployee(CollegeManager sub) {
//分析问题
//1. 这里的 CollegeEmployee 不是 SchoolManager的直接朋友
//2. CollegeEmployee 是以局部变量方式出现在 SchoolManager
//3. 违反了 迪米特法则
//获取到学院员工
List<CollegeEmployee> list1 = sub.getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
//获取到学校总部员工
List<Employee> list2 = this.getAllEmployee();
System.out.println("------------学校总部员工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}

分析:
-
SchoolManager 类的直接朋友类有哪些:Employee、CollegeManager
-
CollegeEmployee是以局部变量方式出现在SchoolManager,所以CollegeEmployee不是SchoolManager的直接朋友,而是一个陌生类,违背了迪米特法则
示例2:使用迪米特法则进行改进
package cn.cqu.principles.demeter;
import java.util.ArrayList;
import java.util.List;
//客户端
public class Demeter1 {
public static void main(String[] args) {
System.out.println("~~~使用迪米特法则的改进~~~");
//创建了一个 SchoolManager 对象
SchoolManager schoolManager = new SchoolManager();
//输出学院的员工id 和 学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
//学校总部员工类
class Employee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//学院的员工类
class CollegeEmployee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//管理学院员工的管理类
class CollegeManager {
//返回学院的所有员工
public List<CollegeEmployee> getAllEmployee() {
List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) { //这里我们增加了10个员工到 list
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id= " + i);
list.add(emp);
}
return list;
}
//输出学院员工的信息
public void printEmployee() {
//获取到学院员工
List<CollegeEmployee> list1 = getAllEmployee();
System.out.println("------------学院员工------------");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
}
}
//学校管理类
class SchoolManager {
//返回学校总部的员工
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<Employee>();
for (int i = 0; i < 5; i++) { //这里我们增加了5个员工到 list
Employee emp = new Employee();
emp.setId("学校总部员工id= " + i);
list.add(emp);
}
return list;
}
//该方法完成输出学校总部和学院员工信息(id)
void printAllEmployee(CollegeManager sub) {
//分析问题
//1. 将输出学院的员工方法,封装到CollegeManager
sub.printEmployee();
//获取到学校总部员工
List<Employee> list2 = this.getAllEmployee();
System.out.println("------------学校总部员工------------");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}

(3)迪米特法则的注意事项和细节
- 迪米特法则的核心是降低类之间的耦合
- 但是注意,由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类之间的耦合关系,并不是要求完全没有依赖关系
3.7 合成复用原则
(1)基本介绍
- 能够使用合成/聚合的方式,就不要使用继承
- 类继承通常为“白箱复用”,对象组合通常为“黑箱复用”
- 继承在某种程度上破坏了封装性,子类父类耦合度高
- 而对象组合则只要求被组合的对象具有良好定义的接口,耦合度低
(2)案例分析
需求:希望类A可以使用类B的两个方法
方式1:继承

- 如果我们只是让B类使用A类的两个方法,使用继承就会让类A和类B的耦合性增强
- 比如说A增加了一个方法operation3(),但B并不想去用它,但是它继承下来了
方式2:
- 依赖

- 聚合:使用set方法传递类A的实例到属性a

- 组合:在创建B的时候,就给属性a进行了实例化

4.设计原则的核心思想
- 1.找出应用中可能需要变化之处,把他们独立出来,不要把他们和哪些不需要变化的代码混在一起
- 2.针对接口编程,而不是实现编程
- 3.为了交互对象之间的松耦合设计而努力
5.设计模式的分类
GOF中的分类如下:

备注:此处采用的是我学习时一种分类,并非GOF中定义的分类
(1)组件协作
- 模板方法模式(Template Method)
- 策略模式(Strategy)
- 观察者模式(Observer)
(2)单一职责
- 装饰者模式(Decorator)
- 桥接模式(Bridge)
(3)对象创建
- 工厂方法模式(Factory Method)
- 抽象工厂模式(Abstract Factory)
- 原型模式(Prototype)
- 建造者模式(Builder)
(4)对象性能
- 单例模式(Singleton)
- 享元模式(Flyweight)
(5)接口隔离
- 外观模式(Facade)
- 代理模式(Proxy)
- 中介者模式(Mediator)
- 适配器模式(Adapter)
(6)状态变化
- 备忘录模式(Memento)
- 状态模式(State)
(7)数据结构
- 组合模式(Composite)
- 迭代器模式(Iterator)
- 职责链模式(Chain of Responsibility)
(8)行为变化
- 命令模式(Command)
- 访问者模式(Visitor)
(9)领域问题
- 解释器模式(Interpreter)
6.使用重构方法来选择要使用的设计模式
- 面向对象设计模式是“好的面向对象设计”——所谓“好的面向对象设计”指的是哪些可以满足“应对变化,提高复用”的设计
- 现代软件设计的特征是:需求的频繁变化,而设计模式的要点是:寻找变化点,然后再变化点处应用设计模式,从而来应对需求的变化。“什么时候,什么地点应用设计模式”比“理解设计模式结构本身”更为重要
- 设计模式的应用不宜先入为主,一上来就使用设计模式是对设计模式的最大误用,没有一步到位的设计模式,敏捷软件开发提倡的“Refactoring to Patterns”,是很好的使用设计模式的方法
- 即先分析没有使用设计模式的时候,我们的代码存在什么问题,违背了什么设计原则,然后再通过重构的方式去修正代码
重构的关键技法:
- 静态---->动态
- 早绑定--->晚绑定
- 继承--->组合
- 编译时依赖--->运行时依赖
- 紧耦合--->松耦合
本文介绍了设计模式的基本概念,探讨了软件设计复杂性的原因,并详细阐述了设计模式的七大原则:单一职责原则、接口隔离原则、依赖倒转原则、里氏代换原则、开放封闭原则、迪米特法则和合成复用原则。通过理解这些原则,开发者可以更好地应对变化,提高代码的可读性和可维护性。
9305

被折叠的 条评论
为什么被折叠?



