河冰结合，非一之日寒；积土成山,非斯须之作

软件工程中，设计模式是对软件设计中普遍存在 (反复出现) 的各种问题，所提出的解决方案

目的是让程序具有更好的

  1. 代码重用性 ( 相同功能的代码，不用多次编写 )
  2. 可读性 ( 编程规范，便于阅读和理解 )
  3. 可扩展性 ( 需求增加时，方便扩展 )
  4. 可靠性 ( 增加新功能后，对原来的功能没有影响 )
  5. 低耦合，高内聚

七大设计原则

设计模式的原则，其实就是程序猿在编程时，应当遵守的原则，也是各种设计模式的基础

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转原则
  • 里氏替换原则
  • 开闭原则
  • 迪米特法则
  • 合成复用原则

单一职责原则

对类来说，一个类应该只负责一项职责。

eg：类 A 负责两个不同的职责：职责 1，职责 2。当职责 1 需求改变时而更改 A，可能会造成 职责 2 的错误。因此需要将类 A 分解为两个类，负责不同的职责。

满足单一职责原则，来保证某一功能的变更不会影响其它的功能 ( 可靠性 )

看一下下面这段简单的代码和它的运行结果

  1. public class SingleResponsibilityOne {
  3.     public static void main(String[] args) {
  5.         Vehicle vehicle = new Vehicle();
  6.         vehicle.run("摩托车");
  7.         vehicle.run("巴士");
  8.         vehicle.run("直升飞机");
  9.     }
  10. }
  13. /**
  14.  * 交通工具类
  15.  * */
  16. class Vehicle{
  18.     public void run(String vehicle){
  19.         System.out.println(vehicle + "在公路上奔跑");
  20.     }
  22. }

设计模式 (上) - 图1

很显然，第三条输出违反了单一职责原则。从 Vehicle 类中的 run 方法看来，这个类的职责应该是只管公路上跑的。因此可以将 Vehicle 类进行拆分 ( 如拆分为：LoadVehicle，SkyVehicle，WaterVehicle 等 )，并将 Vehicle 抽象出来成为父类

例如下面代码

  1. public class SingleResponsibilityThree {
  2.     public static void main(String[] args) {
  4.         BaseVehicle landVehicle = new LandVehicle2();
  5.         BaseVehicle waterVehicle = new WaterVehicle2();
  6.         BaseVehicle skyVehicle = new SkyVehicle2();
  8.         landVehicle.run("巴士");
  9.         waterVehicle.run("邮轮");
  10.         skyVehicle.run("小鸟");
  11.     }
  12. }
  15. class BaseVehicle{
  17.     void run(String vehicle){};
  18. }
  20. class LandVehicle2 extends BaseVehicle{
  22.     @Override
  23.     void run(String vehicle) {
  24.         System.out.println(vehicle + "在地上跑");
  25.     }
  26. }
  28. class WaterVehicle2 extends BaseVehicle{
  30.     @Override
  31.     void run(String vehicle) {
  32.         System.out.println(vehicle + "在水里游");
  33.     }
  34. }
  36. class SkyVehicle2 extends BaseVehicle{
  38.     @Override
  39.     void run(String vehicle) {
  40.         System.out.println(vehicle + "在天上飞");
  41.     }
  42. }

当然，对于这种不 “复杂” 的类，我们可以在方法级别保持单一职责原则

例如下面的代码

  1. public class SingleResponsibilityTwo {
  3.     public static void main(String[] args) {
  4.         VehicleAll vehicleAll = new VehicleAll();
  6.         vehicleAll.runLoad("汽车");
  7.         vehicleAll.runSky("灰机");
  8.         vehicleAll.runWater("潜艇");
  9.     }
  10. }
  12. /**
  13.  *
  14.  * 遵守单一职责原则，保持方法级别的单一职责原则
  15.  *
  16.  */
  17. class VehicleAll{
  19.     public void runLoad(String vehicle) {
  20.         System.out.println(vehicle + "在地上跑");
  21.     }
  23.     public void runWater(String vehicle){
  24.         System.out.println(vehicle + "在水里游");
  25.     }
  27.     public void runSky(String vehicle){
  28.         System.out.println(vehicle + "在天上飞");
  29.     }
  30. }

单一职责原则注意事项和细节

  1. 降低类的复杂度，一个类只负责一项职责
  2. 提高类的可读性，可维护性
  3. 降低变更需求引起的风险
  4. 通常情况下，我们应当准守单一职责原则，只有逻辑足够简单，才可以在代码上违反单一职责原则；只有类中的方法足够少，才可以在方法级别保持单一原则

接口隔离原则

  1. 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

看下下面这张图

设计模式 (上) - 图2

转换为代码后

  1. public class SegregationOne {
  2.     public static void main(String[] args) {
  4.         A a = new A();
  5.         B b = new B();
  7.         C c = new C();
  8.         D d = new D();
  10.         a.depend1(b);  //A类通过接口依赖(使用)B类
  11.         a.depend2(b);
  12.         a.depend3(b);
  14.         c.depend1(d);
  15.         c.depend4(d);
  16.         c.depend5(d);
  17.     }
  18. }
  20. /**
  21.  * 接口
  22.  */
  23. interface Interface1{
  24.     void func1();
  25.     void func2();
  26.     void func3();
  27.     void func4();
  28.     void func5();
  29. }
  31. /**
  32.  * 实现类 B
  33.  */
  34. class B implements Interface1{
  36.     @Override
  37.     public void func1() {
  38.         System.out.println("B实现方法1");
  39.     }
  41.     @Override
  42.     public void func2() {
  43.         System.out.println("B实现方法2");
  44.     }
  46.     @Override
  47.     public void func3() {
  48.         System.out.println("B实现方法3");
  49.     }
  51.     @Override
  52.     public void func4() {
  53.         System.out.println("B实现方法4");
  54.     }
  56.     @Override
  57.     public void func5() {
  58.         System.out.println("B实现方法5");
  59.     }
  60. }
  62. /**
  63.  * 实现类 D
  64.  */
  65. class D implements Interface1{
  67.     @Override
  68.     public void func1() {
  69.         System.out.println("D实现方法1");
  70.     }
  72.     @Override
  73.     public void func2() {
  74.         System.out.println("D实现方法2");
  75.     }
  77.     @Override
  78.     public void func3() {
  79.         System.out.println("D实现方法3");
  80.     }
  82.     @Override
  83.     public void func4() {
  84.         System.out.println("D实现方法4");
  85.     }
  87.     @Override
  88.     public void func5() {
  89.         System.out.println("D实现方法5");
  90.     }
  91. }
  93. /**
  94.  * 依赖类 A
  95.  */
  96. class A{
  98.     public void depend1(Interface1 i){
  99.         i.func1();
  100.     }
  101.     public void depend2(Interface1 i){
  102.         i.func2();
  103.     }
  104.     public void depend3(Interface1 i){
  105.         i.func3();
  106.     }
  107. }
  110. /**
  111.  * 依赖类 C
  112.  */
  113. class C{
  115.     public void depend1(Interface1 i){
  116.         i.func1();
  117.     }
  118.     public void depend4(Interface1 i){
  119.         i.func4();
  120.     }
  121.     public void depend5(Interface1 i){
  122.         i.func5();
  123.     }
  124. }

类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C 来说不是最小接口，那么类 B 和类 D 就必须去实现他们不需要的方法

按照接口隔离原则，应当这样处理

将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系，就达成了接口隔离原则

因此，我们可以对接口做如下拆分

设计模式 (上) - 图3

实现代码如下

  1. public class SegregationTwo {
  2.     public static void main(String[] args) {
  4.         A1 a = new A1();
  5.         B1 b = new B1();
  7.         C1 c = new C1();
  8.         D1 d = new D1();
  10.         a.dependeFun1(b);
  11.         a.dependeFun2(b);
  12.         a.dependeFun3(b);
  14.         c.dependeFun1(d);
  15.         c.dependeFun4(d);
  16.         c.dependeFun5(d);
  17.     }
  18. }
  21. interface Interface11{
  23.     void fun1();
  25. }
  27. interface Interface2{
  29.     void fun2();
  30.     void fun3();
  31. }
  33. interface Interface3{
  35.     void fun4();
  36.     void fun5();
  37. }
  40. /**
  41.  * 实现类 B
  42.  * */
  43. class B1 implements Interface11, Interface2{
  45.     @Override
  46.     public void fun1() {
  47.         System.out.println("B实现接口1的方法1");
  48.     }
  50.     @Override
  51.     public void fun2() {
  52.         System.out.println("B实现接口2的方法2");
  53.     }
  55.     @Override
  56.     public void fun3() {
  57.         System.out.println("B实现接口2的方法3");
  58.     }
  59. }
  62. /**
  63.  * 实现类 D
  64.  */
  65. class D1 implements Interface11, Interface3{
  67.     @Override
  68.     public void fun1() {
  69.         System.out.println("D实现接口1的方法1");
  70.     }
  72.     @Override
  73.     public void fun4() {
  74.         System.out.println("D实现接口3的方法4");
  75.     }
  77.     @Override
  78.     public void fun5() {
  79.         System.out.println("D实现接口3的方法5");
  80.     }
  81. }
  83. /**
  84.  * 依赖类 A
  85.  */
  86. class A1{
  88.     public void dependeFun1(Interface11 i){
  89.         i.fun1();
  90.     }
  92.     public void dependeFun2(Interface2 i){
  93.         i.fun2();
  94.     }
  96.     public void dependeFun3(Interface2 i){
  97.         i.fun3();
  98.     }
  99. }
  102. class C1{
  104.     public void dependeFun1(Interface11 i){
  105.         i.fun1();
  106.     }
  108.     public void dependeFun4(Interface3 i){
  109.         i.fun4();
  110.     }
  112.     public void dependeFun5(Interface3 i){
  113.         i.fun5();
  114.     }
  115. }

依赖倒转原则

依赖倒转原则是指

  1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象
  2. 抽象不应该依赖细节，细节应该依赖抽象
  3. 依赖倒转的中心思想是面向接口编程
  4. 相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 Java 中，抽象指的是接口或抽象类，细节就是具体的实现类
  5. 使用接口或抽象类的目的是制定规范，而不设计任何具体操作，把展现细节的任务交给他们的实现类去完成

看看下面这个例子

  1. public class DependecyInversion {
  2.     public static void main(String[] args) {
  4.         Person person = new Person();
  5.         person.receive(new Email());
  6.     }
  7. }
  10. class Person{
  12.     /**
  13.      * 接收消息
  14.      * @param email: 电子邮件类
  15.      */
  16.     public void receive(Email email){
  17.         System.out.println(email.getInfo());
  18.     }
  19. }
  22. class Email{
  25.     public String getInfo(){
  26.         return "邮件信息：hello";
  27.     }
  29. }

可以看见，Person 类中的方法依赖了 Email 类，很大的弊端就是 Email 这个类的抽象层次太低，而 recevie() 这个方法的抽象层次太高，如果传来的是来自微信，QQ，短信等不同类的消息，那么使用 Email 接收显然就是错误的了。

因此可以抽象出接口，然后 recevie() 依赖于这个接口，可以接收来自于不同类的消息

  1. public class DependecyInversionBetter {
  2.     public static void main(String[] args) {
  4.         Email1 email1 = new Email1();
  5.         WeiXin weiXin = new WeiXin();
  6.         Person1 person1 = new Person1();
  8.         person 1.recevie(email1);
  9.         person1.recevie(weiXin);
  10.     }
  11. }
  13. /**
  14.  * 抽象出的接口
  15.  */
  16. interface GetInfo{
  17.     String getInfo();
  18. }
  20. class Email1 implements GetInfo{
  22.     @Override
  23.     public String getInfo() {
  24.         return "电子邮件信息：hello ";
  25.     }
  26. } 
  28. class WeiXin implements GetInfo{
  30.     @Override
  31.     public String getInfo() {
  32.         return "微信信息：hello ";
  33.     }
  34. }
  36. class Person1{
  38.     public void recevie(GetInfo getInfo){
  39.         System.out.println(getInfo.getInfo());
  40.     }
  41. }

依赖关系传递的三种方式

  • 接口传递
  • 构造函数传递
  • setter 方法传递

依赖倒转原则的注意事项和细节

  1. 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好
  2. 变量的声明类型尽量是抽象类或接口，这样变量引用和实际对象间就存在一个缓冲层，利于程序扩展和优化
  3. 继承时遵循里氏替换原则

里氏替换原则

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能

继承带来的弊端

  1. 父类中凡是已经实现了的方法，实际上是在设定规范，虽然其并不要求子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏
  2. 继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合，如果一个类被其他类所继承，则当这个类需要修改时，必须考虑到所有的子类。父类修改后，所有涉及到父类的功能都可能出现故障

里氏替换原则其实是告诉我们继承需要注意的问题和需要遵守的规则

里氏替换原则的基本内容

  • 如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的功能行为没有发生变化，那么类型 T2 就是类型 T1 的子类型。
    即：所有引用基类的地方必须能透明地使用其子类对象

  • 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类方法

  • 在适当的情况下，继承造成的耦合性问题，可以通过聚合，组合，依赖等关系来解决

来看看下面这段代码

  1. public class LiExchangePrincple {
  2.     public static void main(String[] args) {
  4.         A a = new A();
  5.         System.out.println("20-7="+a.fuc1(20, 7));
  6.         System.out.println("1-10="+a.fuc1(1, 10));
  8.         B b = new B();
  9.         System.out.println("20-7="+b.fuc1(20, 7));
  10.         System.out.println("1-10="+b.fuc1(1, 10));
  11.         System.out.println("11+3+9="+b.fuc2(11, 3));
  12.     }
  13. }
  15. /**
  16.  * 类 A
  17.  */
  18. class A{
  19.     /**
  20.      *
  21.      * @param num1
  22.      * @param num2
  23.      * @return：两个数的差
  24.      */
  25.    public int fuc1(int num1, int num2){
  26.        return num1-num2;
  27.    }
  28. }
  30. /**
  31.  * 类 B, 继承类 A
  32.  */
  33. class B extends A{
  35.     @Override
  36.     public int fuc1(int a, int b){
  37.         return a+b;
  38.     }
  40.     /**
  41.      *
  42.      * @param a
  43.      * @param b
  44.      * @return：两数相加后再与9相加，然后返回
  45.      */
  46.     public int fuc2(int a, int b){
  47.         return fuc1(a, b) + 9;
  48.     }
  49. }

设计模式 (上) - 图4

很明显，由于 B 类修改了从 A 类继承下来的方法，导致结果不是我们想要的

通常的改进方法是：原来的父类和子类都继承一个更加通用的基类，去掉原有的继承关系，采用依赖，聚合，组合等关系代替

因此，可以更改为如下代码

  1. public class LiExchangePrincpleBetter {
  2.     public static void main(String[] args) {
  4.         A1 a = new A1();
  5.         System.out.println("20-7="+a.fuc1(20, 7));
  6.         System.out.println("1-10="+a.fuc1(1, 10));
  8.         B1 b = new B1();
  9.         System.out.println("20-7="+b.fuc1(20 ,7));
  10.         System.out.println("1-10="+b.fuc1(1, 10));
  11.         System.out.println("11+3+9="+b.fuc2(11, 3));
  12.     }
  13. }
  15. class Base{
  17.     public int fuc1(int num1, int num2){
  18.         return num1-num2;
  19.     }
  20. }
  22. class A1 extends Base{
  25. }
  27. class B1 extends Base{
  29.     public int fuc2(int a, int b){
  30.         return fuc1(a, b)+9;
  31.     }
  32. }

B1 在父类 Base 的基础上，只做增加不做修改

开闭原则

  • 开闭原则是编程中最基础，最重要的设计原则
  • 一个软件实体中的类，模块，函数等应该面向扩展开放(对提供方)，面向修改关闭(对使用方)，即扩展了提供方的代码后，使用方的代码不用做修改
  • 用抽象构建框架，用实现扩展细节
  • 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化
  • 在编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则

看下下面这段代码

  1. public class OpenAndClose {
  2.     public static void main(String[] args) {
  4.         GraphEditorUtils graphEditor = new GraphEditorUtils();
  5.         graphEditor.drawShape(new Cricle());
  6.         graphEditor.drawShape(new ZhengFangXing());
  7.     }
  8. }
  10. /**
  11.  * 绘图工具类
  12.  */
  13. class GraphEditorUtils{
  15.     public void drawShape(Shape shape){
  16.         if(shape.type == 1){
  17.             drawCricle();
  18.         }else if(shape.type == 2){
  19.             drawZhengFang();
  20.         }
  21.     }
  23.     private void drawCricle(){
  24.         System.out.println("画一个圆形");
  25.     }
  27.     private void drawZhengFang(){
  28.         System.out.println("画一个正方形");
  29.     }
  31. }
  33. class Shape{
  34.     //图形类型
  35.     int type;
  36. }
  38. class Cricle extends Shape{
  40.     public Cricle(){
  41.         super.type = 1;
  42.     }
  43. }
  45. class ZhengFangXing extends Shape{
  47.     public ZhengFangXing(){
  48.         super.type = 2;
  49.     }
  50. }

这种方式其实并不满足开闭原则，当我们需要新增加一个图形 ( 如三角形时 )，需要做如下修改

  1. public class OpenAndClose {
  2.     public static void main(String[] args) {
  4.         GraphEditorUtils graphEditor = new GraphEditorUtils();
  5.         graphEditor.drawShape(new Cricle());
  6.         graphEditor.drawShape(new ZhengFangXing());
  8.         //增加绘制三角
  9.         graphEditor.drawShape(new SanJiao());
  10.     }
  11. }
  13. /**
  14.  * 绘图工具类，使用方
  15.  */
  16. class GraphEditorUtils{
  18.     public void drawShape(Shape shape){
  19.         if(shape.type == 1){
  20.             drawCricle();
  21.         }else if(shape.type == 2){
  22.             drawZhengFang();
  23.         }else if(shape.type == 3){
  24.             drawSanJiao();
  25.         }
  26.     }
  28.     private void drawCricle(){
  29.         System.out.println("画一个圆形");
  30.     }
  32.     private void drawZhengFang(){
  33.         System.out.println("画一个正方形");
  34.     }
  36.     /**
  37.      * 由于新增了一个图形，因此需要在使用方新增一个方法
  38.      */
  39.     private void drawSanJiao(){
  41.     }
  43. }
  45. class Shape{
  46.     //图形类型
  47.     int type;
  48. }
  50. class Cricle extends Shape{
  52.     public Cricle(){
  53.         super.type = 1;
  54.     }
  55. }
  57. class ZhengFangXing extends Shape{
  59.     public ZhengFangXing(){
  60.         super.type = 2;
  61.     }
  62. }
  64. /**
  65.     新增三角形类
  66. */
  67. class SanJiao extends Shape{
  69.     public SanJiao(){
  70.         super.type = 3;
  71.     }
  72. }

很明显，我们在使用方修改了代码，这并不满足开闭原则

因此，我们可以改进，比如将 Shape 做成抽象类或接口，然后增加一个 draw() 方法。这样就只需要让新的图形类继承或者实现 Shape，并实现 draw() 方法即可

  1. public class OpenAndCloseBetter {
  2.     public static void main(String[] args) {
  4.         GraphEditorUtils1 graphEditor = new GraphEditorUtils1();
  5.         graphEditor.drawShape(new Cricle1());
  6.         graphEditor.drawShape(new ZhengFangXing1());
  8.         //增加绘制三角
  9.         graphEditor.drawShape(new SanJiao1());
  10.     }
  11. }
  13. class GraphEditorUtils1{
  15.     public void drawShape(Shape1 shape){
  16.        shape.draw();
  17.     }
  18. }
  20. abstract class Shape1{
  21.     //图形类型
  22.     int type;
  24.     abstract public void draw();
  25. }
  27. class Cricle1 extends Shape1{
  29.     @Override
  30.     public void draw() {
  31.         System.out.println("画圆");
  32.     }
  33. }
  35. class ZhengFangXing1 extends Shape1{
  37.     @Override
  38.     public void draw() {
  39.         System.out.println("画正方形");
  40.     }
  41. }
  43. class SanJiao1 extends Shape1{
  45.     @Override
  46.     public void draw() {
  47.         System.out.println("画三角");
  48.     }
  49. }

在这种情况下，新增一个新的图形，并不需要修改使用方的代码，满足 ocp 原则

迪米特法则

迪米特法则又叫做最少知道原则，即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管其多么复杂，都尽量把逻辑封装在类的内部，对外除了提供 public 的方法，不再泄露其它任何信息

  1. 一个对象应该对其他对象保持最少的了解
  2. 类与类的关系越密切，耦合度越高

迪米特法则有一个抽象的说法：只与直接的朋友通信

直接的朋友：每个对象都会与其它对象产生耦合关系，只要两个对象之间有耦合关系，就称两个对象之间是朋友关系。其中，称出现在成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，最好不要将其它对象以局部变量的形式放在类的中

  1. /**
  2.  * 有一个学校，下属各个学院和总部
  3.  * 现打印出学校总部员工id和学院员工的id
  4.  */
  5. public class DimiTe {
  6.     public static void main(String[] args) {
  8.         SchoolManager schoolManager = new SchoolManager();
  9.         schoolManager.printAllEmployee(new CollegeManager());
  10.     }
  11. }
  13. /**
  14.  * 学校总部员工类
  15.  */
  16. class Employee {
  17.     private String id;
  19.     public void setId(String id) {
  20.         this.id = id;
  21.     }
  23.     public String getId() {
  24.         return id;
  25.     }
  26. }
  28. /**
  29.  * 学院员工类
  30.  */
  31. class CollegeEmployee {
  32.     private String id;
  34.     public void setId(String id) {
  35.         this.id = id;
  36.     }
  38.     public String getId() {
  39.         return id;
  40.     }
  41. }
  43. /**
  44.  * 学院管理类
  45.  */
  46. class CollegeManager {
  48.     /**
  49.      *
  50.      * @return: 学院所有员工
  51.      */
  52.     public List<CollegeEmployee> getAllEmployee() {
  54.         List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();
  55.         for (int i = 0; i < 10; i++) {
  56.             CollegeEmployee emp = new CollegeEmployee();
  57.             emp.setId("学院员工id= " + i);
  58.             list.add(emp);
  59.         }
  60.         return list;
  61.     }
  62. }
  64. /**
  65.  * 学校总部管理类
  66.  */
  67. class SchoolManager {
  69.     public List<Employee> getAllEmployee() {
  71.         List<Employee> list = new ArrayList<Employee>();
  72.         for (int i = 0; i < 5; i++) {
  73.             Employee emp = new Employee();
  74.             emp.setId("学校总部员工id= " + i);
  75.             list.add(emp);
  76.         }
  77.         return list;
  78.     }
  80.     /**
  81.      *
  82.      * @param sub：学院管理类
  83.      */
  84.     void printAllEmployee(CollegeManager sub) {
  86.         //获取所有的学院员工
  87.         List<CollegeEmployee> list1 = sub.getAllEmployee();
  88.         System.out.println("------------学院员工------------");
  89.         for (CollegeEmployee e : list1) {
  90.             System.out.println(e.getId());
  91.         }
  92.         //获取所有的学校总部员工
  93.         List<Employee> list2 = this.getAllEmployee();
  94.         System.out.println("------------学校总部员工------------");
  95.         for (Employee e : list2) {
  96.             System.out.println(e.getId());
  97.         }
  98.     }
  99. }

分析一下这段代码中的 SchoolManager 类中，有哪些直接朋友和陌生人

方法参数，方法返回值，成员变量上的对象称为直接朋友，所以 SchooleManager 的直接朋友有：Employee，CollegeManager

陌生人有：CollegeEmployee，以局部变量的方式出现在了 SchoolManager 中

因此违背了迪米特法则

对于这段代码，通过分析可得知，主要是因为

  1.         //获取所有的学院员工
  2.         List<CollegeEmployee> list1 = sub.getAllEmployee();
  3.         System.out.println("------------学院员工------------");
  4.         for (CollegeEmployee e : list1) {
  5.             System.out.println(e.getId());
  6.         }

这里导致了迪米特法则的不满足，因此我们可以将这段代码拆分到 CollegeManager 类中成为一个 public 的方法，再通过调用来满足迪米特法则

  1. public class DiMiteBetter {
  2.     public static void main(String[] args) {
  4.         SchoolManager1 schoolManager1 = new SchoolManager1();
  5.         schoolManager1.printAllEmployee(new CollegeManager1());
  6.     }
  7. }
  10. /**
  11.  * 学校总部员工类
  12.  */
  13. class Employee1 {
  14.     private String id;
  16.     public void setId(String id) {
  17.         this.id = id;
  18.     }
  20.     public String getId() {
  21.         return id;
  22.     }
  23. }
  25. /**
  26.  * 学院员工类
  27.  */
  28. class CollegeEmployee1 {
  29.     private String id;
  31.     public void setId(String id) {
  32.         this.id = id;
  33.     }
  35.     public String getId() {
  36.         return id;
  37.     }
  38. }
  40. /**
  41.  * 学院管理类
  42.  */
  43. class CollegeManager1 {
  45.     /**
  46.      *
  47.      * @return: 学院所有员工
  48.      */
  49.     public List<CollegeEmployee1> getAllEmployee() {
  51.         List<CollegeEmployee1> list = new ArrayList<>();
  52.         for (int i = 0; i < 10; i++) {
  53.             CollegeEmployee1 emp = new CollegeEmployee1();
  54.             emp.setId("学院员工id= " + i);
  55.             list.add(emp);
  56.         }
  57.         return list;
  58.     }
  60.     /**
  61.      * 获取所有学院员工
  62.      */
  63.     public void printAllEmployee() {
  65.         //获取所有的学院员工
  66.         List<CollegeEmployee1> list1 = this.getAllEmployee();
  67.         System.out.println("------------学院员工------------");
  68.         for (CollegeEmployee1 e : list1) {
  69.             System.out.println(e.getId());
  70.         }
  71.     }
  72. }
  74. /**
  75.  * 学校总部管理类
  76.  */
  77. class SchoolManager1 {
  79.     public List<Employee1> getAllEmployee() {
  81.         List<Employee1> list = new ArrayList<>();
  82.         for (int i = 0; i < 5; i++) {
  83.             Employee1 emp = new Employee1();
  84.             emp.setId("学校总部员工id= " + i);
  85.             list.add(emp);
  86.         }
  87.         return list;
  88.     }
  90.     /**
  91.      * 获取所有员工
  92.      */
  93.     void printAllEmployee(CollegeManager1 sub) {
  95.         //通过直接朋友调用其中的方法
  96.         sub.printAllEmployee();
  98.         //获取所有的学校总部员工
  99.         List<Employee1> list2 = this.getAllEmployee();
  100.         System.out.println("------------学校总部员工------------");
  101.         for (Employee1 e : list2) {
  102.             System.out.println(e.getId());
  103.         }
  104.     }
  105. }

迪米特法则的注意事项和细节

  • 迪米特法则的核心是降低类之间的耦合
  • 但是，由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间 ( 对象间 ) 耦合关系，并不是要求完全没有耦合关系

合成复用原则

尽量使用合成 / 聚合等耦合度较低的关系，而不是使用继承

总结

设计原则的核心思想

  • 找出应用中可能需要变化的地方，把他们独立出来，不要和那些不需要变化的代码混在一起
  • 面向接口编程，而不是面向实现编程
  • 为了交互对象之间的松耦合设计而努力

UML 类图

UML 统一建模语言，是一种用于软件系统分析和设计的语言工具

UML 本身是一套符号的规定，这些符号用于描述软件模型中的各个元素和他们之间的关系。如：类，接口，实现，泛化，依赖，组合，聚合等

UML 类图的关系

  • 依赖 (使用) 设计模式 (上) - 图5
  • 关联 ( 1:n，n:1 等关系) 设计模式 (上) - 图6
  • 泛化 (继承) 设计模式 (上) - 图7
  • 实现 设计模式 (上) - 图8
  • 聚合 设计模式 (上) - 图9 是关联关系的特例
  • 组合 设计模式 (上) - 图10 是关联关系的特例

UML 的分类

  • 用例图
  • 静态结构图：类图，对象图，包图，组件图，部署图
  • 动态行为图：交互图 ( 时序图和协作图 )，状态图，活动图

类图是 UML 中最核心的

将代码转化为类图

  1. class Person{
  3.     private Integer id;
  4.     private String name;
  6.     public void setName(String name){
  7.         this.name = name;
  8.     }
  10.     public String getName(){
  11.         return this.name;
  12.     }
  13. }

设计模式 (上) - 图11

idea 自带类转类图的功能，右键即可

依赖，泛化，实现

依赖

只要在类中用到了对方，那么两者之间就存在依赖关系

设计模式 (上) - 图12

箭头指向被依赖的类

泛化

泛化关系其实就是继承关系，是依赖关系的特例

设计模式 (上) - 图13

实现

实现关系就是一个类实现另一个类 (接口)，也是依赖关系的特例

设计模式 (上) - 图14

关联，聚合，组合

关联

关联关系就是类与类之间的联系，也是依赖关系的特例

关联具有导航性，即双向关系和单向关系

同也有一对一，多对一，一对多，多对多的多重性

如

  1. //单向一对一关系
  2. public class Person{
  3.     private IDCard card;
  4. }
  5. public class IDCard{ }
  7. //双向一对一关系
  8. public class Person{
  9.     private IDCard card;
  10. }
  11. public class IDCard{
  12.     private Person person;
  13. }

聚合

聚合关系表示的是整体和部分的关系，整体和部分可以分开。聚合关系是关联关系的特例，所以聚合关系具有关联关系的导航性和多重性

如：一台电脑由键盘，显示器，鼠标等组成。而组成电脑的这些配件是可以从电脑上分离出来的，这种情况下认为键盘，显示器，鼠标等配件和电脑的关系是聚合关系

  1. public class Computer{
  2.     private Mouse mouse;
  3.     private Moniter moniter;
  5.     public void setMouse(Mouse mouse){
  6.         this.mouse = mouse;
  7.     }
  9.     public void setMoniter(Moniter moniter){
  10.         this.moniter = moniter;
  11.     }
  13. }

Computer 中的 Mouse，Moniter 在 Computer 创建时是不存在的，只有在需要的时候才会 set (聚合) 进去

设计模式 (上) - 图15

组合

组合关系，也是整体与部分的关系，但是整体与部分是不可分的

借用聚合关系的例子，如果我们认为 Mouse，Moniter 和 Computer 是不可分离的，则升级为组合关系

  1. public class Computer{
  2.     private Mouse mouse = new Mouse();
  3.     private Moniter moniter = new Moniter();
  4. }

在这个例子下，如果我们创建了一个 Computer 对象，那 Mouse 和 Moniter 也会被融入其中，成为 Computer 不可分离的一部分

设计模式 (上) - 图16

比如：Person，IDCard，Head。在这三个实体中，Person 和 Head 就是组合关系，Person 和 IDCard 就是聚合关系

但是，如果在程序中， Person 实体类定义了对 IDCard 的级联删除，即删除 Person 时连同 IDCard 一起删除，那么 IDCard 和 Person 就是组合了