设计个网站要多少钱,wordpress采集模块,wordpress 伪链接,山东高阳建设公司网站1.设计模式经典面试题分析几个常见的设计模式对应的面试题。1.1原型设计模式1.使用UML类图画出原型模式核心角色#xff08;意思就是使用会考察使用UML画出设计模式中关键角色和关系图等#xff09;2.原型设计模式的深拷贝和浅拷贝是什么#xff0c;写出深拷贝的两种方式的源…1.设计模式经典面试题 分析几个常见的设计模式对应的面试题。1.1原型设计模式 1.使用UML类图画出原型模式核心角色意思就是使用会考察使用UML画出设计模式中关键角色和关系图等 2.原型设计模式的深拷贝和浅拷贝是什么写出深拷贝的两种方式的源码重写clone方法实现深拷贝使用序列化实现深拷贝 考察对原型模式细节的理解。 3.Spring框架中哪里需要进行使用原型模式 分析框架中设计模式的体现。 4.分析代码Debug Debug水平如何会分析设计模式代码嘛1.2解释器设计模式1.2.1解释器设计模式本身的理解 1.介绍解释器模式是什么 其实就是看对这个设计模式的理解如何。 2.画出解释器设计模式的UML类图分析其中的各个角色是什么 其实就是在考察会不会进行画原型图会不会通过原型图去分析其中的整体结构1.2.2解释器设计模式在Spring框架的理解 1.请说明Spring的框架中哪里使用到了解释器模式进行源码级分析 其实就是进行考察对框架中一些关键功能的实现其中的设计模式理解的如何。 2.对于解释器模式在Spring框架中的应用有哪些Spring框架中SpelExpressionParser使用的就是解释器模式。代码分析Debug源码说明。1.3单例设计模式 单例设计模式一共有多少种实现方式请分别使用代码进行实现并分析其中的优缺点。 1.饿汉式 两种。 2.懒汉式 三种。 3.双重检查。 4.静态内部类。 5.枚举。 所以说单例设计模式一共八种。1.4场景题1.4.1问题再现 拼多多抢单项目拼多多抢单的订单有审核-发布-抢单等步骤随着操作的不同会改变订单的状态项目中这个抢单的模块就是使用状态模式进行设计的请你使用状态模式进行设计一下。 其实其中就是给定一个场景并提示/不提示给你使用什么设计模式进行实现在有限的时间内思考出问题的解决方案。1.4.2问题解决 如果使用if-else进行判断各种状态会显得整体代码十分臃肿不便于维护如果在其中发现哪个状态没有进行处理之类的就会出现问题所以可以进行使用状态设计模式来进行解决。2.设计模式中的七大原则 设计模式在进行设计的时候均需要进行遵循七大OOP原则来进行设计。 1.单一职责原则。 2.接口隔离原则。 3.依赖倒转原则。 4.里氏替换原则。 5.开闭原则OCP。 6.迪米特法则。 7.合成复用原则。3.设计模式的重要性3.1软件工程中的解决方案 设计模式是一种解决方案是对软件设计中普遍存在的问题进行提出的一种解决方案是前人的经验的智慧可以进行解决软件工程中的一些特定问题。3.2使用设计模式架构的好处 设计模式可以为软件工程带来良好的架构体系不注意软件架构设计的项目草草收工的项目就想一个简易的房子没有进行良好的设计就肯定不会建立成为一个高楼大厦。 借助设计模式对整个项目进行良好的架构设计才可以建立起坚固的地基最终可以依据坚固的地基架构起高楼大厦。3.3设计模式便于扩展新功能 一个项目需要进行扩展新功能的时候如果没有良好的软件架构设计那么将是十分艰难的很有可能添加了这个功能别的地方就会出现问题了需要到处改正。3.4设计模式可以提供可维护性 如果进行胡乱的设计堆砌代码不注重设计整个项目只会导致整个项目可读性越来越差可维护性越来越差最终导致这个项目变成一个破烂玩意烂尾楼。 使用设计模式进行良好架构之后项目的整体可读性可维护性可以提高。3.5设计模式解决面试问题 两个人在学历条件等同或者上下浮动一级的情况下你设计模式玩的六六的他设计模式一窍不通当然是你可以取得offer抱的Offer归。3.6设计模式在软件中的引用 1.进行面向对象OOP设计时可以进行使用。 2.进行设计功能模块时 可以使用设计模式算法数据结构的集合。 3.框架使用到多种设计模式 4.架构架构整个软件设计使得软件设计变得更为合理3.7设计模式的目的 1.代码可用性相同的代码一次编写即可无需进行多次编写 2.可读性提高代码的可读性 3.可扩展性增加新功能时会非常方便不会导致增加新功能的时候对其它功能有很大的影响 4.可靠性设计模式使得整个软件工程的可靠性提高 5.使得整个项目达到高内聚低耦合的特性4.详解设计模式七大原则4.1单一职责原则4.1.1什么是单一职责原则 对于类来说一个类仅仅负责一项职责如果一个类进行负责两个不同的职责当因为职责一需要进行改动增强的时候可能会导致职责二出现问题所以要对A类进行按职责细分为两个类使得两个类负责自己的职责达到类单一职责的目的。4.1.2单一职责的案例4.1.2.1不遵循单一职责 如果一个类的不遵循单一职责一个方法进行设计为可以进行处理多个职责那么就会出现问题。 例如下面这个SingleResposibility类中进行定义了一个action开始出发的方法可以进行处理任意类型的交通工具进行启动执行但是你会发现这样进行使用会出现问题。
/*** 单一职责设计模式*/
public class SingleResponsibility {public static void action(Vehicle vehicle) {System.out.println(vehicle.getName() 在路上行走);}public static void main(String[] args) {Car car new Car(汽车);action(car);Plant plant new Plant(飞机);action(plant);}}abstract class Vehicle {protected String name;public abstract String getName();
}class Car extends Vehicle {public Car(String name) {this.name name;}Overridepublic String getName() {return name;}}class Plant extends Vehicle {public Plant(String name) {this.name name;}Overridepublic String getName() {return name;}
} 看一下运行结果 会发现这个类并没有把多职责问题给处理好多职责会出现一定的问题。 并且如果我们再去修改处理多职责的代码对于另一个职责的处理也会出现问题。
public static void action(Vehicle vehicle) {System.out.println(vehicle.getName() 在天上飞行);
} 发现确实出现了一定的问题 当我们进行修改想要兼容另一个职责的时候发现对原来的职责发生了影响所以这就是当一个类进行处理多职责的时候会出现一定的问题。4.1.2.2修复遵循单一职责 将类中的方法进行职责拆分让每个方法进行具有单一职责的功能这样就解决了刚刚的问题。 对于每个类如果一个类中的方法少就可以将方法拆分为单一职责的方法如果一个类中方法比较多就将这个类拆分为多个遵循单一职责的类让每个类都具有单一职责这样就可以解决一定的问题。
/*** 单一职责设计模式*/
public class SingleResponsibility {public static void carAction(Car car) {System.out.println(car.getName() 在路上行驶);}public static void plantAction(Plant plant) {System.out.println(plant.getName() 在天上飞行);}public static void main(String[] args) {Car car new Car(汽车);carAction(car);Plant plant new Plant(飞机);plantAction(plant);}} 可以发现这样就没问题啦4.1.2.2修复遵循单一职责 将类中的方法进行职责拆分让每个方法进行具有单一职责的功能这样就解决了刚刚的问题。 对于每个类如果一个类中的方法少就可以将方法拆分为单一职责的方法如果一个类中方法比较多就将这个类拆分为多个遵循单一职责的类让每个类都具有单一职责这样就可以解决一定的问题。 可以发现这样就没问题啦4.1.3单一职责原则注意事项和细节 1.单一职责原则可以降低复杂度使得一个类只进行负责一项职责。 2.提高类的可读性和可维护性 很容易理解出来一个类仅仅去负责一个职责。 3.降低变更引起的风险 一个类中如果负责多个职责当修改A职责的时候存在影响B职责代码的风险。 4.遵循类级别的单一职责原则还是方法级别的单一职责原则 如果类比较简单的时候可以在一个类中进行处理多个职责使用方法去区分每个职责即可如果类比较复杂建议进行对类进行拆分为多个具有单一职责的类这样就可以降低类的复杂性提高可维护性。4.2接口隔离原则4.2.1基本介绍 客户端不应该依赖它不需要进行依赖的接口也就是一个类对另一个类的依赖需要进行建立在最小接口上。4.2.2建模分析 先进行简单建模分析一下目前进行定义了一个接口interface1里面进行定义了五个抽象方法。 B和D进行实现了interface1中的五个方法。 A和C通过依赖于interface1接口调用B和D中的方法。 如果A和C去分别依赖B和D中的方法时将接口中所有的方法都进行调配使用了就可以认为是达到了接口隔离原则类去依赖于其它类的时候建立在了最小接口上。4.2.3不规范代码分析4.2.3.1定义的抽象接口
// 抽象接口
interface Interface1 {void operation1();void operation2();void operation3();void operation4();void operation5();
}4.2.3.2定义的实现类B和实现类D
// 实现类B
class B implements Interface1 {Overridepublic void operation1() {System.out.println(B进行操作1);}Overridepublic void operation2() {System.out.println(B进行操作2);}Overridepublic void operation3() {System.out.println(B进行操作3);}Overridepublic void operation4() {System.out.println(B进行操作4);}Overridepublic void operation5() {System.out.println(B进行操作5);}}
// 实现类D
class D implements Interface1 {Overridepublic void operation1() {System.out.println(D进行操作1);}Overridepublic void operation2() {System.out.println(D进行操作2);}Overridepublic void operation3() {System.out.println(D进行操作3);}Overridepublic void operation4() {System.out.println(D进行操作4);}Overridepublic void operation5() {System.out.println(D进行操作5);}
}4.2.3.3定义的依赖类A和依赖类C
// 类A
class A {public void depend1(Interface1 interface1) {interface1.operation1();}public void depend2(Interface1 interface1) {interface1.operation2();}public void depend3(Interface1 interface1) {interface1.operation3();}}// 类C
class C {public void depend1(Interface1 interface1) {interface1.operation1();}public void depend4(Interface1 interface1) {interface1.operation4();}public void depend5(Interface1 interface1) {interface1.operation5();}}4.2.3.4不规范代码分析 可以发现B和D两个实现类实现了整个接口中的所有方法但是A和C两个类进行依赖于两个实现类进行调用方法的时候并没有进行使用接口中定义的所有方法都只是依赖了一部分方法这样就不是建立在最小接口上了出现了实现方法冗余的情况打破了接口隔离原则。4.2.4接口隔离的的改进策略 为了保证A类依赖B类的时候建立在最小接口上需要进行遵循接口隔离原则。 1.类A通过接口interface1依赖B类C通过接口interface1依赖类D如果接口interface1对于A类和C类来说都不是最小接口接口中存在冗余方法A和C无法进行利用那么B类和D类必须去实现A类和C类不需要的方法。 2.将接口interface1拆分为几个接口类A和类C分别去和需要的接口建立依赖关系实现接口隔离原则。4.2.5遵循接口隔离后的规范代码 进行按接口隔离的规范进行修改代码。4.2.5.1定义的抽象接口
// 抽象接口
interface Interface1 {void operation1();
}interface Interface2 {void operation2();void operation3();
}interface Interface3 {void operation4();void operation5();
}4.2.5.2定义的实现类B和实现类D
// 实现类B
class B implements Interface1, Interface2 {Overridepublic void operation1() {System.out.println(B进行操作1);}Overridepublic void operation2() {System.out.println(B进行操作2);}Overridepublic void operation3() {System.out.println(B进行操作3);}}// 实现类D
class D implements Interface1, Interface3 {Overridepublic void operation1() {System.out.println(D进行操作1);}Overridepublic void operation4() {System.out.println(D进行操作4);}Overridepublic void operation5() {System.out.println(D进行操作5);}
}4.2.5.3定义的依赖类A和依赖类C
// 类A
class A {public void depend1(Interface1 interface1) {interface1.operation1();}public void depend2(Interface2 interface1) {interface1.operation2();}public void depend3(Interface2 interface1) {interface1.operation3();}}// 类C
class C {public void depend1(Interface1 interface1) {interface1.operation1();}public void depend4(Interface3 interface1) {interface1.operation4();}public void depend5(Interface3 interface1) {interface1.operation5();}}4.3依赖倒转原则4.3.1基本介绍 依赖倒转原则指的是 1.高层模块不应该依赖底层模块二者都应该依赖于抽象。 2.抽象不应该依赖于细节细节应该依赖于抽象。 3.依赖倒转倒置的中心思想就是面向接口编程。 4.依赖倒转基于的设计理念相对于细节的多变性抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在Java中抽象指的是接口和抽象类细节就是具体的实现类。 5.使用接口或者抽象类的目的时制定好规范而不涉及到任何具体的操作吧展现细节的任务交给他们的实现类去完成。4.3.2建模分析 下面这个UML类图表示的就是一个非常不规范的结构分析Person可以进行接收邮件消息和微信消息但是由于邮件消息和微信消息是两个类所以Person就进行定义了两个方法进行接收Email/WX消息但是这个设计不是一个优秀的设计因为这个设计没有进行遵循依赖倒转原则没有进行抽象化设计其实Email和Wx这两个类都可以进行抽象为Message消息类让实现类都去继承Message消息抽象类让不同消息类去实现Message抽象类并自定义消息发送的逻辑。 Person类去使用一个方法只去接收Message抽象类即可。4.3.3不规范的代码分析4.3.3.1两个消息类
class Email {public String getInfo() {return 电子邮件信息: Hello, world;}
}class Wx {public String getInfo() {return 微信信息: 土皇帝牛逼;}
}4.3.3.2Person使用者类
class Person extends Wx {public void receive(Email email) {System.out.println(email.getInfo());}public void receiveWX(Wx wx) {System.out.println(wx.getInfo());}
}4.3.3.3不规范设计的总结 每多一个消息渠道Person使用者就需要多增加一个代码这就是不使用抽象去架构的坏处违反了依赖倒转原则。4.3.4规范代码的设计4.3.4.1抽象类Message的架构设计 使用抽象去架构设计。
abstract class Message {public abstract String getInfo();
}4.3.4.2各种消息类的架构设计
class Email extends Message {Overridepublic String getInfo() {return 电子邮件信息: Hello, world;}
}class Wx extends Message {Overridepublic String getInfo() {return 微信信息: 土皇帝牛逼;}
}4.3.4.3Person使用者类
class Person {public void receive(Message message) {System.out.println(message.getInfo());}
}4.3.4.4建模分析 使用抽象架构设计的方式让Person类仅仅使用一个方法就可以接收所有按抽象类Message设计的类的对象增强了架构设计简化了Person使用的类的冗余性。4.3.5依赖关系传递的三种方式和应用案例 1.接口传递依赖关系 使用接口向类中进行传递依赖对象。 2.构造方法传递依赖关系 使用构造方法向类中进行传递依赖对象。 3.setter方法传递依赖关系 使用setter方法向类中进行传递依赖对象。4.3.6通过接口传递依赖4.3.6.1定义依赖接口
// ITV接口
interface ITV {void play();void stop();
}4.3.6.2定义操作接口
// 开关的接口
interface IOpenAndClose {void open(ITV tv);void close(ITV tv);
}4.3.6.3定义实现接口
// 实现接口
class OpenAndClose implements IOpenAndClose {Overridepublic void open(ITV tv) {tv.play();}Overridepublic void close(ITV tv) {tv.stop();}
}4.3.6.4总结使用接口传递依赖 接口传递依赖是什么呢其实就是通过实现接口的方式将依赖给注入到类中进行使用。 通过下面的UML建模图可以观察到其中的玄机 ITV其实就是依赖类的抽象接口IOpenAndClose是动作类的抽象接口当动作类去实现了抽象接口之后抽象接口就会通过抽象方法强制性地将依赖ITV注入到实现类中。4.3.7通过构造方法传递依赖4.3.7.1定义依赖接口
// ITV接口
interface ITV {void play();void stop();
}4.3.7.2定义操作接口
// 开关的接口
interface IOpenAndClose {void open();void close();
}4.3.7.3定义实现接口
// 实现接口
class OpenAndClose implements IOpenAndClose {private ITV tv;public OpenAndClose(ITV tv) {this.tv tv;}Overridepublic void open() {tv.play();}Overridepublic void close() {tv.stop();}
}4.3.7.4总结使用构造方法传递依赖 构造方法传递依赖其实就是将依赖对象使用构造方法的形式传递过来在字段中进行存储。存储到类的字段中后进行在类内部进行使用。4.3.8通过Setter方法进行传递4.3.8.1定义依赖接口
// ITV接口
interface ITV {void play();void stop();
}4.3.8.2定义操作接口
// 开关的接口
interface IOpenAndClose {void open();void close();
}4.3.8.3定义实现接口
// 实现接口
class OpenAndClose implements IOpenAndClose {private ITV tv;public void setTv(ITV tv) {this.tv tv;}Overridepublic void open() {tv.play();}Overridepublic void close() {tv.stop();}
}4.3.8.4总结使用setter方法传递依赖 setter方法主要是使用setter方法将数据进行注入到类的字段中在类的内部进行使用。4.3.9依赖倒转原则的注意事项和细节1.底层模块尽量都要有抽象类或者接口或者两者都有程序稳定性更好。 也就是说底层的模块最好先使用抽象类或者接口进行抽象设计再使用底层模块类进行实现保证了程序的阔拓展性。2.变量的声明类型尽量是抽象类或者接口这样我们的变量引用和实际对象间就存在一个缓冲层利于程序扩展和优化。 其实就是例如A是继承自B的我们要进行实例化的时候最好不要进行指定实例化A指定类型是B最好因为这样可以在变量引用和实际对象间存在一个缓冲层。这个缓冲层可以起到一个便于扩展的作用。 为什么便于扩展呢 因为如果我们想要进行扩展对象的功能的时候可以不去直接修改A类里面的内容去扩展B类父类的内容也可以进行达到扩展对象的能力如果父类的方法达不到要求可以进行Override重写父类中的方法使用多态达到重写方法的目的。 所以多层缓冲可以提高整体的可扩展性和维护性。3.继承遵循里氏替换原则。4.4里氏替换原则4.4.1什么是里氏替换原则1.继承包含的一层含义子类不可随意更改父类方法 打破契约 父类中凡是实现好的方法实际上是在设定规范和契约虽然不强制要求所有子类必须遵循这些契约但是如果子类对这些已经实现的方法随意修改会给整个继承体系带来巨大的破坏。2.继承带来的弊端 继承给程序带来了侵入性程序的可移植性降低增加了对象之间的耦合性如果一个类被其它的类所继承则当这个类需要进行修改时必须考虑到所有的子类并且父类修改后所有涉及到子类的功能都有可能出现故障。3.里氏替换原则可以保障正确的使用继承 里氏替换原则其实就是子类可以进行直接替换掉基类型并且替换掉之后不会出现任何问题即子类替换掉基类后与基类原本的行为特征表示一致子类不能随便去重写基类中的方法。4.4.2违反里氏替换原则的典型 这个例子就是违反了里氏替换原则B1可以进行替换掉A1但是B1重写了A1中的方法使得自己内部的方法和原本基类中方法行为不一致违反了里氏替换原则。
/*** 违反里氏替换原则*/
public class RichterSubstitution {public static void main(String[] args) {A1 a1 new A1();System.out.println(11 - 3 a1.func1(11, 3));System.out.println(---------------------------);B1 b1 new B1();System.out.println(11 - 3 b1.func1(11, 3));System.out.println(11 3 9 b1.func2(11, 3));}}class A1 {public int func1(int num1, int num2) {return num1 - num2;}
}class B1 extends A1 {Overridepublic int func1(int a, int b) {return a b;}public int func2(int a, int b) {return func1(a, b) 9;}
}4.4.3遵循里氏替换原则的方案4.4.3.1出现问题的原因 出现问题的原因其实就是因为类B无意重写了父类中的方法造成了原有功能出现了错误。在实际编程中常常会通过重写父类的方法完成新的功能这样虽然写起来简单但是整个继承体系的复用性会变差。特别是当运行堕胎比较频繁的时候。 所以尽量不要无意重写方法遵循里氏替换原则提高继承体系的复用性。4.4.3.2出现问题的原因 通用的做法是原来的父类和子类都继承一个更通俗的基类原有的继承关系去掉采用依赖聚合组合等关系代替。4.4.4遵循里氏替换原则的代码 准备Base基类让B1和A1均去继承Base基础类将A1中不被B1重写的方法都放在Base基类中这样一方面达到了继承公有方法提高了代码复用性第二方面又不会破坏里氏替换原则保留了继承的复用性。
// 准备一个基类
class Base {// 将更基础的方法和成员写到Base基类中
}// A1类
class A1 extends Base {// 返回两个数的差public int func1(int num1, int num2) {return num1 - num2;}
}class B1 extends Base {public int func1(int a, int b) {return a b;}public int func2(int a, int b) {return func1(a, b) 9;}
}4.5开闭原则 最重要的原则 1.开闭原则是编程中最基础最重要的设计原则。 2.一个软件实体如类模块和函数应该对扩展开放对提供方对修改关闭对使用方。用抽象构建框架用实现扩展细节。 3.当软件需要变化的时候尽量通过扩展软件实体的行为来实现变化而不是通过已有代码来实现变化。 4.编程中遵循其它原则以及使用设计模式的目的就是遵循开闭原则。4.5.1违反开闭原则的典型 很容易可以发现这就是一个违反开闭原则的典型开闭原则中我们要进行遵守对提供者开放对使用者关闭的原则在这里我们区分出1职责其中提供者就是Shape的子类Rectangle和Circle使用者就是GaphicEditor使用者接收这些类的实例对象的时候是写死里面的可以发现drawShape去接收的是Shape类型的实例但是仅仅定义了两个分支如果提供者进行增加数据就会出现问题并且将不同类型的shape的执行操作定义在了GraphicEditor中如果提供者进行修改代码新增一个Shape的实现类就会出现问题就要去修改GraphicEditor中的代码。 当我们去修改GraphicEditor中的代码的时候就违反了开闭原则因为我们进行改动了使用者中的代码所以说这段代码违反了开闭原则。4.5.1.1提供方代码
class Shape {int type;
}class Rectangle extends Shape {public Rectangle() {super.type 1;}
}class Circle extends Shape {public Circle() {super.type 2;}
}4.5.1.2使用方代码
class GraphicEditor {public void drawShape(Shape shape) {if (shape.type 1) {drawRectangle(shape);} else if (shape.type 2) {drawCircle(shape);}}public void drawRectangle(Shape shape) {System.out.println(矩形);}public void drawCircle(Shape shape) {System.out.println(圆形);}
}4.5.2遵循开闭原则的修改方式 开闭原则要进行保障对使用者关闭对提供者开放所以可以将Shape定义为抽象类提供一个抽象的draw方法让子类都去实现这样当又新的图像种类时仅仅需要让新的图像类去继承Shape并实现draw方法即可这样就保证了只需要去修改提供者增强提供者不需要去修改使用者。 其实就是让使用者aware感知不到提供者发生了变化进行了完美的解耦合。4.5.3遵循开闭原则的代码4.5.3.1提供方代码
abstract class Shape {int type;public abstract void draw();
}class Rectangle extends Shape {public Rectangle() {super.type 1;}Overridepublic void draw() {System.out.println(矩形);}
}class Circle extends Shape {public Circle() {super.type 2;}Overridepublic void draw() {System.out.println(圆形);}
}4.5.3.2使用方代码
class GraphicEditor {public void drawShape(Shape shape) {shape.draw();}}4.6迪米特法则4.6.1什么是迪米特法则1.一个对象应该对其它对象保持最少的了解 其实就是设计类的时候将字段都设置为private私有的如果想要外部对象进行访问/更改自己内部的状态使用getter/setter函数即可。2.类与类关系越密切耦合度越大 假设有两个类类A和类B如果类A中的字段/方法依赖于类B中的static字段/实例化对象中的实例字段就称为类A和类B中有关系如果这种关系越密切字段使用越多则代表类A和类B和耦合度大。3.迪米特法则 最少知道原则 一个类对依赖自己的类知道的越少越好。也就是说对于被依赖的类不管多复杂都要尽量将逻辑封装在类的内部。对外除了进行提供public方法不要对外泄漏任何信息。尽量将自己对外开放的逻辑都封装在public方法中不要进行对外暴露更多的信息。4.迪米特法则更简单的定义 仅仅与直接朋友通信。5.直接的朋友 什么是直接的朋友每个对象都会与其它对象有耦合关系只要两个对象之间有耦合关系我们就说两个对象之间是朋友关系。 耦合的方式都有什么依赖关联聚合等。其中我们称出现成员变量方法参数方法返回值中的类为直接的朋友而出现在局部变量的类不是直接的朋友。 其实意思就是说不要让陌生的类以局部变量的方式出现在类的内部。4.6.2违反迪米特法则的典型4.6.2.1定义的学院员工类和学院管理类1.学院员工类
/*** 学院员工类*/
public class CollegeEmployee {private String id;public void setId(String id) {this.id id;}public String getId() {return id;}
}2.学院管理类
import java.util.ArrayList;
import java.util.List;/*** 管理学院员工的管理类*/
public class CollegeManager {// 返回学院的所有员工public ListCollegeEmployee getAllEmployee() {ListCollegeEmployee list new ArrayList();for (int i 0; i 10; i) {CollegeEmployee emp new CollegeEmployee();emp.setId(学院员工ID i);list.add(emp);}return list;}
}4.6.2.2定义的学院员工类和学院管理类1.学校员工类
/*** 学校总部员工*/
public class Employee {private String id;public void setId(String id) {this.id id;}public String getId() {return id;}
}2.学院管理类
import java.util.ArrayList;
import java.util.List;// 学校管理类
public class SchoolManager {// 返回学校总部的员工public ListEmployee getAllEmployee() {ListEmployee list new ArrayList();for (int i 0; i 10; i) {Employee emp new Employee();emp.setId(学校总部员工ID i);list.add(emp);}return list;}// 使用该方法进行输出学校总部和学院总部员工信息idvoid printAllEmployee(CollegeManager sub) {ListCollegeEmployee list1 sub.getAllEmployee();System.out.println(------------计算机科学学院的员工-------------);for (CollegeEmployee e : list1) {System.out.println(e.getId());}System.out.println(------------学校总部的员工-------------);ListEmployee list2 getAllEmployee();for (Employee e : list2) {System.out.println(e.getId());}}
}4.6.2.3问题所在 问题主要是出现在printAllEmployee这个方法中在SchoolManager这个类的的printAllEmployee方法中进行使用了局部变量ListCollegeEmployee进行其它类没有遵循迪米特法则使用了非直接朋友局部变量。4.6.3问题解决4.6.3.1解决方案 解决这个问题十分简单只需要进行将打印学院管理的员工的这段逻辑封装抽取到学院类中在SchoolManager中的printAllEmployee中进行调用学院封装的打印学院管理的员工的逻辑即可这样就不会不遵循迪米特法则了。4.6.3.2抽取逻辑到学院类中
public void printAllEmployee() {ListCollegeEmployee list1 getAllEmployee();System.out.println(------------计算机科学学院的员工-------------);for (CollegeEmployee e : list1) {System.out.println(e.getId());}
}4.6.3.3在学校类中调用封装的学院方法
// 使用该方法进行输出学校总部和学院总部员工信息id
void printAllEmployee(CollegeManager collegeManager) {collegeManager.printAllEmployee();System.out.println(------------学校总部的员工-------------);ListEmployee list2 getAllEmployee();for (Employee e : list2) {System.out.println(e.getId());}
}4.6.3.4这样封装到底解决了什么问题 为什么要遵循迪米特法则将局部变量给取消呢封装为一个方法有什么好处呢 先做一个抽象理解将SchoolManager抽象为类A将College抽象为类B将方法printAllEmployee抽象为方法K。 其实我们就可以理解A类在K方法中进行局部依赖了B其实这是一个很不好的行为如果类B进行发生了改变那么A的方法势必会受到影响必须要去更改A中的逻辑其实这也违反了开闭原则在这里完全可以将类A抽象为使用者类B抽象为提供者提供者发生更改的时候使用者也需要更改这样是不是就违反了开闭原则造成了问题的出现。 所以说我们将类A依赖类B的逻辑部分抽象到类B中定为方法M让A去调用M这样如果B发生了变化只要B能修改M让M的行为保持不变就不会影响A类中K方法做到了下层类修改上层类无感知的设计模式真正实现了遵循迪米特法则解耦合。4.6.4迪米特法则需要注意点 1.迪米特法则的核心 将降低类之间的耦合。 2.但是注意由于每个类都减少了不必要的依赖所以迪米特法则只是要求降低类间对象间耦合关系不是要求做到完全没有依赖关系。4.7合成复用原则 合成复用原则Composite Reuse Principle4.7.1什么是合成复用原则 原则是尽量使用合成/聚合的方式而不是使用继承。4.7.2继承的缺点 - 增强耦合 假设我们现在有两个类类A和类B类A具有强大的能力方法类B是一个废材B类很渴望和A类一样强大那么我们可以进行使用继承帮它嘛。4.7.2.1定义具有强大能力的A类 A类狂的不行毕竟太有实力了此时他在大街上携带者三个强大的能力方法溜达着。
/*** 定义一个父类A*/
public class A {public void operation1() {System.out.println(进行了操作1);}public void operation2() {System.out.println(进行了操作2);}public void operation3() {System.out.println(进行了操作3);}
}4.7.2.2定义废材B类 B类看见A类金光闪闪必是一个强大人物扑通一声B类跪下说大哥请赐给我力量A类微微抬头得意一笑说你喊我声爹认我当你爹我就给你力量B类思索片刻心情十分复杂脑海中回忆着往事又浮现出对未来获取强大的能力后的幻想在A类就要离开之时B类抬起头大喊父亲my DadI would get your force 于是B类成为了A类的儿子继承得到了A类的力量。
/*** 渴望拥有能力方法的B类*/
public class B extends A {
}4.7.2.3测试B类的力量 B得到了满足回到家乡展示给大家看他从A类中继承出来的能力。
/*** 测试类*/
public class Test {public static void main(String[] args) {B b new B();b.operation1();b.operation2();b.operation3();}}4.7.2.4继承带来的代价 继承太重了会增强类之间的强耦合性如果仅仅是想要去获取方法使用不建议使用继承的方式去获取。 因为继承会带来很重的耦合关系B类直接变成A类的儿子这操作难道不重4.7.3解决方案 像仅仅是去借用一个类中的方法不是为了在层次上进行设计不建议进行使用继承继承应该是在层次上有设计需求的时候进行使用比较好如果没有设计需求不建议去使用这个因为耦合性实在是太强了。 解决方案其实就是将继承的方案替换为合成依赖聚合组合的方式来进行使用其它类中的方法而不是使用继承这样就可以做到解耦合。4.7.4使用合成依赖解决问题 合成依赖其实就是B中哪里需要调用A中的方法在B中需要调用的方法中将A对象作为参数传进去这样就可以在B需要的地方去调用A中的方法了这就是合成依赖4.7.4.1定义具有强大能力的A类 在你面前的仍然是具有强大能力的A类。
/*** 定义一个父类A*/
public class A {public void operation1() {System.out.println(进行了操作1);}public void operation2() {System.out.println(进行了操作2);}public void operation3() {System.out.println(进行了操作3);}}4.7.4.2定义废材B类 B类这次没有认A当爹而是进行在自己的方法中去调用A中的方法进行使用其实就是一个狐假虎威。
/*** 渴望拥有能力方法的B类*/
public class B {public void operation1(A a) {a.operation1();}public void operation2(A a) {a.operation2();}public void operation3(A a) {a.operation3();}
}4.7.4.3总结使用合成解决问题 使用合成依赖的方式其实就是进行在B的方法中进行接收一个A类型的参数调用A中的方法进行使用这样就实现了脱离继承体系去使用A中的方法的目的。4.7.5使用聚合解决问题 聚合就是在类B中定义一个类A的字段使用setter方法为类B设置类A字段的A实例对象。4.7.5.1定义具有强大能力的A类 A类没变化不贴代码啦。4.7.5.2定义废材B类
/*** 渴望拥有能力方法的B类*/
public class B {private A a;public void setA(A a) {this.a a;}public void operation1() {a.operation1();}public void operation2() {a.operation2();}public void operation3() {a.operation3();}
}4.7.6使用组合解决问题 组合就是直接进行在B类中的A字段中new出来一个A对象进行使用这样就是组合。4.7.6.1定义具有强大能力的A类 A类没变化不贴代码啦。4.7.6.2定义废材B类 可以看见确实是在B类中的A字段中直接进行new了一个A对象出来进行使用。
/*** 渴望拥有能力方法的B类*/
public class B {private A a new A();public void operation1() {a.operation1();}public void operation2() {a.operation2();}public void operation3() {a.operation3();}
}
