【关键字】设计模式的原则设计模式 uml类图一站式消化吸收学习

词汇学习
IoC (Inversion of Control) 控制反转
依赖注入(DI)

【引用】
【设计模式】http://www.uml.org.cn/sjms/201211023.asp
【x-a关系说明】http://blog.csdn.net/cbk861110/article/details/9028189
【uml类图】http://www.cnblogs.com/alex-blog/articles/2704214.html
【设计模式大的分类】http://blog.csdn.net/jason0539/article/details/44956775
【各种工厂模式】http://www.cnblogs.com/toutou/p/4899388.html

一、uml类图

UML类图的标记语言我都忘了我记了多少遍，忘了多少遍了！只有捋出来头绪和关联，才可能永远记住并融入你的思维方式，没有任何联系的东西，我们大脑是不擅长处理的！
总的来说我们的类图分为两大类
is-a和has-a
is-a 可以分为继承和实现，依据：是否有实体函数实现来继承，如果虚函数，则为实现
has-a：包括四种关联关系的，组合，聚合，关联和依赖，依据关系强弱排名

is a 继承/泛化和实现
图标：空心三角箭头，叫上实线或者虚线，父亲有遗产，我就很实在，真心实意，如果父亲啥也没有，是接口，都是虚的，只有理想让我继承，那么我来实现，我的线就是虚的。
继承和实现都是is-a，但是如果父类是接口类，那么就是实现了，因为接口类除了虚函数，啥也没有，没有遗产的父亲，怎么继承呢？所以叫实现，父亲没有遗产，我来实现父亲的遗愿，哈哈

继承

实现

组合>聚合>关联>依赖；
通过类图，可以发现图的规律

组合

聚合

关联

依赖

通过图的变化关系，可以发现，关系性越强的，箭头内容就越多，比如组合，实线，有实心菱形，关系越弱的，箭头内容越少，比如依赖，虚线，没有菱形。简直是大发现!

下面的几个都是contain-a，has-a，relate-a,rely-a

contains-a 组合关系，包含关系，强聚合
组合关系是局部和整体不可分开的，脑仁和脑袋的关系，分开了就不好了，要死人的！
我和我的大脑也是这个关系，不能缺少局部单元；

组合，菱形是实心的，说明这个局部实实在在的忠诚于我，不会离开我

has a 聚合关系
是可以分割的，比如一袋子食品，袋子里装着馒头和包子，那么礼物袋和馒头包子就是聚合，随时可以分离

聚合，菱形空心

关联
长期关系，比如朋友，同事关系，都是长期性的，非临时性的

关联-长期稳定关系

依赖

依赖-最脆弱的关系，临时性，脆弱性

二、设计模式原则-六大原则

六脉神剑，要帮我们干掉的毒性代码
new（对象创建）是有毒的

public class MovieLister {
    private MovieFinder finder;

    public MovieLister() {
        finder = new MovieFinderImpl();
    }
    
    public Movie[] moviesDirectedBy(String arg) {
        List allMovies = finder.findAll();
        for (Iterator it = allMovies.iterator(); it.hasNext();) {
            Movie movie = (Movie) it.next();
            if (!movie.getDirector().equals(arg)) it.remove();
        }
        return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]);
    }
    ...
}

2.1、设计原则深度理解【此小节引用知乎的一个问答】

https://www.zhihu.com/question/19582024

那些年，空气中仿佛还能闻到汉唐盛世的余韵，因此你决不允许自己的脸上有油光，时刻保持活力。然而，你一定曾为这些“高深术语”感到过困扰。也许时至今日，你仍对它们一知半解。不过就在今天，这一切都将彻底改变！我将带领你以一种全新的高清视角进入奇妙的编程世界，领略涵泳在这些“高深术语”中的活泼泼的地气，以及翩跹于青萍之末的云水禅心。

image

·内聚

内聚，通俗的来讲，就是自己的东西自己保管，自己的事情自己做。

经典理论告诉我们，程序的两大要素：一个是数据（data），一个是操作（opration）。而 PASCAL之父Nicklaus Wirth则进一步提出了“程序 = 数据结构 + 算法”的著名公式。虽然提法上有所差异，但是其根本内涵却是一致的，微妙的差别在于，“数据 + 操作”是微观的视域，“数据结构 + 算法”则是中观的视域。而在宏观的视域下，我认为“程序 = 对象 + 消息”。对象是什么？对象就是保管好自己的东西，做好自己的事情的程序模块——这就是内聚！传统的面向过程编程方法由于割裂了数据结构和算法，使得软件的内聚性普遍低迷，曾一度引发了软件危机。试想，大家都自己的东西不好好保管，自己的事情也不好好做，不引发危机才怪呢！当然，对象的内聚只是内聚的一个层次，在不同的尺度下其实都有内聚的要求，比如方法也要讲内聚，架构也要讲内聚。

《周易·彖传》中讲“乾道变化，各正性命，保合太和，乃利贞”，就是要求每一个个体因循着各自的禀赋而努力成就各自的品性，然后各自保全，彼此和合，最终达成宇宙的完满状态。《论语·宪问》中，子路问君子。子曰：“修己以敬。”曰：“如斯而已乎？”曰：“修己以安人”，更是明确的教导我们要不断提高自身的内聚性，最大限度地减少给他人造成的麻烦，从而达到安人、安百姓、安天下的目标。我想，成长的过程就是一个不断提升内聚的过程。“自己的东西自己保管，自己的事情自己做”，这些孩提时代的教诲，放到今天仍能让不少“大人”脸红不已。太多的人保管不好自己的“东西”，保管不好自己的身体，保管不好自己的婚姻，更保管不好自己如蛛丝般震颤飘荡的狂乱的心。至于做好自己的事情，则更是惘然，甚至很多人连自己的事情是什么都搞不清楚，因此浑浑噩噩，饱食终日。内聚，是一个值得我们好好反思的问题。

·依赖·耦合

在面向对象编程中，对象自身是内聚的，是保管好自己的数据，完成好自己的操作的，而对外界呈现出自己的状态和行为。但是，没有绝对的自力更生，对外开放也是必要的！一个对象，往往需要跟其他对象打交道，既包括获知其他对象的状态，也包括仰赖其他对象的行为，而一旦这样的事情发生时，我们便称该对象依赖于另一对象。只要两个对象之间存在一方依赖一方的关系，那么我们就称这两个对象之间存在耦合。比如妈妈和baby，妈妈要随时关注baby的睡、醒、困、哭、尿等等状态，baby则要仰赖妈妈的喂奶、哄睡、换纸尿裤等行为，从程序的意义上说，二者互相依赖，因此也存在耦合。首先要说，耦合是必要的。我们来看以下这个实验。

【王阳明与山中之花】

View Code

由于王阳明这个对象不依赖山花这个对象，又没有其他的方式来获知山花的盛开状态，所以他要么选择不说，要么瞎说，但不说编译是通不过，而瞎说作为王阳明来讲也是通不过的，所以这个系统是无法成立的。要想系统成立，必须要这样写：

        public bool AdmireFlowers()
        {
            return flower.IsBloomed; ; 
        }

无论这个山花对象是怎么来的，作为参数传入还是作为属性设置、还是在内部构造出来，总之，王阳明与山花之间发生了依赖，二者之间产生了耦合。当然，这是一个很浅显的问题。有趣的是王阳明对此事的看法：“你未看花时，花与你同寂；你来看花，花于你则一时分明起来。可见心外无物！”王阳明讲的是对的！“心外无物”翻译技术语言是这样的：不存在耦合的两个对象必然拿不到对方的引用！

·耦合度·解耦和

耦合的程度就是耦合度，也就是双方依赖的程度。上文所说的妈妈和baby就是强耦合。而你跟快递小哥之间则是弱耦合。一般来说耦合度过高并不是一件好事。就拿作为IT精英的你来说吧，上级随时敦促你的工作进度，新手频繁地需要你指导问题，隔三差五还需要参加酒局饭局，然后还要天天看领导的脸色、关注老婆的心情，然后你还要关注代码中的bug 、bug、bug，和需求的变化、变化、变化，都够焦头烂额了，还猝不及防的要关注眼睛、颈椎、前列腺和头发的状态，然后你再炒个股，这些加起来大概就是个强耦合了。从某种意义上来说，耦合天生就与自由为敌，无论是其他对象依赖于你，还是你依赖其他对象。比如有人嗜烟、酗酒，你有多依赖它们就有多不自由；比如有人家里生了七八个娃，还有年迈的父母、岳父母，他们有多依赖你，你就有多不自由。所以老子这样讲：“五音令人耳聋，五色令人目盲，驰骋狩猎令人心发狂，难得之货令人行妨。”卢梭也是不无悲凉的说“人生而自由，却又无往而不在枷锁中”。因此，要想自由，就必须要降低耦合，而这个过程就叫做解耦和。

·依赖倒置（Dependence Inversion Principle）

解耦和最重要的原则就是依赖倒置原则：

高层模块不应该依赖底层模块，他们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。

《资本论》中都曾阐释依赖倒转原则——在商品经济的萌芽时期，出现了物物交换。假设你要买一个IPhone，卖IPhone的老板让你拿一头猪跟他换，可是你并没有养猪，你只会编程。所以你找到一位养猪户，说给他做一个养猪的APP来换他一头猪，他说换猪可以，但是得用一条金项链来换——所以这里就出现了一连串的对象依赖，从而造成了严重的耦合灾难。解决这个问题的最好的办法就是，买卖双发都依赖于抽象——也就是货币——来进行交换，这样一来耦合度就大为降低了。

再举一个编程中的依赖倒置的例子。我们知道，在通信中，消息的收发和消息的处理往往密不可分。就一般的通信框架而言，消息的收发通常是已经实现了的，而消息的处理则是需要用户来自定义完成的。先看一个正向依赖的例子：轻量级通信引擎StriveEngine。tcpServerEngine是StriveEngine.dll提供通信引擎，它发布有一个MessageReceived事件。假设我定义了一个CustomizeHandler类来用于消息处理，那么CustomizeHandler的内部需要预定tcpServerEngine的MessageReceived事件，因此customizeHandler依赖于tcpServerEngine，这就是一个普通的依赖关系，也就是高层模块依赖于低层模块。

image

image

而ESFramework通信框架则应用了依赖倒转原则。ESFramework定义了一个IcustomizeHandler接口，用户在进行消息处理时，实现该接口，然后将其注入到rapidPassiveEngine客户端通信引擎之中。

View Code

很明显，相比于上一个例子，这里的依赖关系变成了rapidPassiveEngine依赖于customizeHandler，也就是说依赖关系倒置了过来，上层模块不再依赖于底层模块，而是它们共同依赖于抽象。rapidPassiveEngine依赖的是IcustomizeHandler接口类型的参数，customizeHandler同样是以实现的接口的方式依赖于IcustomizeHandler——这就是一个依赖倒置的典范。

控制反转（Inversion of Control）

控制反转跟依赖倒置是如出一辙的两个概念，当存在依赖倒置的时候往往也存在着控制反转。但是控制反转也有自己的独特内涵。
框架将调用开发人员的代码，而不是其他方式。该框架实际上是一个可扩展的结构，它为开发人员提供了一组注入自定义代码段的切入点。

引用
https://coyee.com/article/12113-three-design-patterns-that-use-inversion-of-control-sitepoint
这篇博客：主要思想就是控制反转依靠三种方式(以来注入，观察者模式，模板方法)实现，然后框架调用用户的代码，用户将实现代码依靠接口传递给框架

首先我们要区分两个角色，server 跟 Client，也就是服务方和客户方。提供服务端的一方称为服务方，请求服务的一方称为客户方。我们最熟悉的例子就是分布式应用的C/S架构，服务端和客户端。其实除此之外，C/S关系处处可见。比如在TCP/IP协议栈中，我们知道，每层协议为上一层提供服务，那么这里就是一个C/S关系。当我们使用开发框架时，开发框架就是作为服务方，而我们自己编写的业务应用就是客户方。当Client调用server时，这个叫做一般的控制；而当server调用Client时，就是我们所说的控制反转，同时我们也将这个调用称为“回调”。控制反转跟依赖倒置都是一种编程思想，依赖倒置着眼于调用的形式，而控制反转则着眼于程序流程的控制权。一般来说，程序的控制权属于server，而一旦控制权交到Client，就叫控制反转。比如你去下馆子，你是Client餐馆是server。你点菜，餐馆负责做菜，程序流程的控制权属于server；而如果你去自助餐厅，程序流程的控制权就转到Client了，也就是控制反转。

image

控制反转的思想体现在诸多领域。比如事件的发布/ 订阅就是一种控制反转，GOF设计模式中也多处体现了控制反转，比如典型的模板方法模式等。而开发框架则是控制反转思想应用的集中体现。比如之前所举的ESFramework通信框架的例子，通信引擎回调用户自定义的消息处理器，这就是一个控制反转。以及ESFramework回调用户自定义的群组关系和好友关系，回调用户自定义的用户管理器以管理在线用户相关状态，回调用户自定义的登陆验证处理，等等不一而足。再比如与ESFramework一脉相承的轻量级通信引擎StriveEngine，通过回调用户自定义的通信协议来实现更加灵活的通信。

由此我们也可以总结出开发框架与类库的区别：使用开发框架时，框架掌握程序流程的控制权，而使用类库时，则是应用程序掌握程序流程的控制权。或者说，使用框架时，程序的主循环位于框架中，而使用类库时，程序的主循环位于应用程序之中。框架会回调应用程序，而类库则不会回调应用程序。ESFramework和StriveEngine中最主要的对象都以engine来命名，我们也可以看出框架对于程序主循环的控制——它会为你把握方向、眼看前方、轻松驾驭！

·依赖注入(Dependency Injection)
【啊哈】大家有没有注意到，我们的c语言的函数内部就是利用形参来进行普通的逻辑实现和运算，然后实际需要用到的数据以实参传入，依赖注入就像函数的参数一样，把实体对象或者函数指针传入，不改变框架的代码，而框架中的代码以 function定义的函数指针进行逻辑实现，或者以形参中的对象或者类进行实现，实际使用的时候传入外部的对象或者函数即可！道理如出一辙，很好理解！

构造函数的参数注入

public class MovieLister {
    private MovieFinder finder;

    public MovieLister(MovieFinder finder) {
        this.finder = finder;
    }
    ...
}

setter注入

public class MovieLister {
    s...
    public void setFinder(MovieFinder finder) {
        this.finder = finder;
    }
}

接口注入
接口注入使用接口来提供setter方法，其实现方式如下

public interface InjectFinder {
    void injectFinder(MovieFinder finder);
}

class MovieLister implements InjectFinder {
    ...
    public void injectFinder(MovieFinder finder) {
      this.finder = finder;
    }
    ...
}

依赖注入与依赖倒置、控制反转的关系仍旧是一本万殊。依赖注入，就其广义而言，即是通过“注入”的方式，来获得依赖。我们知道，A对象依赖于B对象，等价于A对象内部存在对B对象的“调用”，而前提是A对象内部拿到了B对象的引用。B对象的引用的来源无非有以下几种：A对象内部创建（无论是作为字段还是作为临时变量）、构造器注入、属性注入、方法注入。后面三种方式统称为“依赖注入”，而第一种方式我也生造了一个名词，称为“依赖内生”，二者根本的差异即在于，我所依赖的对象的创建工作是否由我自己来完成。当然，这个是广义的依赖注入的概念，而我们一般不会这样来使用。我们通常使用的，是依赖注入的狭义的概念。不过，直接陈述其定义可能会过于诘屈聱牙，我们还是从具体的例子来看。

image

比如OMCS网络语音视频框架，它实现了多媒体设备（麦克风、摄像头、桌面、电子白板）的采集、编码、网络传送、解码、播放（或显示）等相关的一整套流程，可以快速地开发出视频聊天系统、视频会议系统、远程医疗系统、远程教育系统、网络监控系统等等基于网络多媒体的应用系统。然而，OMCS直接支持的是通用的语音视频设备，而在某些系统中，需要使用网络摄像头或者特殊的视频采集卡作为视频源，或者其它的声音采集设备作为音频源，OMCS则提供了扩展接口——用户自己实现这个扩展的接口，然后以“依赖注入”的方式将对象实例注入到OMCS中，从而完成对音、视频设备的扩展。

“依赖注入”常常用于扩展，尤其是在开发框架的设计中。从某种意义上来说，任何开发框架，天生都是不完整的应用程序。因此，一个优秀的开发框架，不仅要让开发者能够重用这些久经考验的的卓越的解决方案，也要让开发者能够向框架中插入自定义的业务逻辑，从而灵活自由地适应特定的业务场景的需要——也就是说要具备良好的可扩展性。比如上面提到的OMCS网络语音视频框架可应用于音、视频聊天系统、视频会议系统、远程医疗系统、远程教育系统、网络监控系统等等基于网络多媒体的应用系统；以及ESFramework通信框架能够应用于即时通讯系统，大型多人在线游戏、在线网页游戏、文件传送系统、数据采集系统、分布式OA系统等任何需要分布式通信的软件系统中——这种良好的扩展性都与“依赖注入”的使用密不可分！

·面向接口编程

谈到最后，“面向接口编程”已经是呼之欲出。无论是依赖倒置、控制反转、还是依赖注入，都已经蕴含着“面向接口编程”的思想。面向接口，就意味着面向抽象。作为哲学范畴而言，规定性少称为抽象，规定性多称为具体。而接口，就是程序中的一种典型的“抽象”的形式。面向抽象，就意味着面向事物的本质规定性，摆脱感性杂多的牵绊，从而把握住“必然”——而这本身就意味着自由，因为自由就是对必然的认识。

也许以上的这段论述太过“哲学”，但是“一本之理”与“万殊之理”本身就“体用不二”——总结来看，依赖倒置、控制反转、依赖注入都围绕着“解耦和”的问题，而同时自始至终又都是“面向接口编程”的方法——因此，“面向接口编程”天生就是“解耦和”的好办法。由此也印证了从“抽象”到“自由”的这一段范畴的辩证衍化。

“面向对象”与“面向接口”并非两种不同的方法学，“面向接口”其实是“面向对象”的内在要求，是其一部分内涵的集中表述。我们对于理想软件的期待常被概括为“高内聚，低耦合”，这也是整个现代软件开发方法学所追求的目标。面向对象方法学作为现代软件开发方法学的代表，本身就蕴含着“高内聚，低耦合”的思想精髓，从这个意义上来说，“面向对象”这个表述更加侧重于“高内聚”，“面向接口”的表述则更加侧重于“低耦合”——不过是同一事物的不同侧面罢了。

除此之外，我们也能从“面向接口编程”的思想中得到“世俗”的启迪——《论语》里面讲，不患无位，患所以立；不患人之不己知，患其不能也——就是教导我们要面向“我有没有的本事？”、“我有没有能力？”这样的接口，而不是面向“我有没有搞到位子？”、“别人了不了解我？”这样的具体。依我看，这是莫大的教诲！

2.2 六大原则详细讲解

单一原则
【】定义：
不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
【】问题由来：
类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
依赖倒置原则
就是尽量依赖接口，不要依赖具体实现，依赖一个很少变化的对象，如果你依赖的实现对象老是变化，那你岂不是也要跟着老是改动，这样很不爽，对吧！
【】定义：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
【】问题由来：
类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
【】解决方案：
将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了
接口隔离原则
【】定义：
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
【】问题由来：
类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

没有遵守最小接口原则的依赖关系

遵守了接口最小原则的依赖关系

通过这两个图，可以很容易发现，最小接口原则，就是提取公因数到一个接口里边，向上面的I1，方法1都提取到了这个接口中

里式替换原则
肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。
【】定义1：
如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
【】定义2：
所有引用基类的地方必须能透明地使用其子类的对象。
【】问题由来：
有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
【】解决方案：
当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
继承包含这样一层含义：
父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
迪米特原则
【】定义：
一个对象应该对其他对象保持最少的了解。
【】问题由来：
类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
【】解决方案：
尽量降低类与类之间的耦合。
【】简介：
迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。
【】看下面这个例子
举一个例子：有一个集团公司，下属单位有分公司和直属部门，现在要求打印出所有下属单位的员工ID。先来看一下违反迪米特法则的设计。

//总公司员工
class Employee{
    private String id;
    public void setId(String id){
        this.id = id;
    }
    public String getId(){
        return id;
    }
}

//分公司员工
class SubEmployee{
    private String id;
    public void setId(String id){
        this.id = id;
    }
    public String getId(){
        return id;f
    }
}

class SubCompanyManager{
    public List getAllEmployee(){
        List list = new ArrayList();
        for(int i=0; i<100; i++){
            SubEmployee emp = new SubEmployee();
            //为分公司人员按顺序分配一个ID
            emp.setId("分公司"+i);
            list.add(emp);
        }
        return list;
    }
}

class CompanyManager{

    public List getAllEmployee(){
        List list = new ArrayList();
        for(int i=0; i<30; i++){
            Employee emp = new Employee();
            //为总公司人员按顺序分配一个ID
            emp.setId("总公司"+i);
            list.add(emp);
        }
        return list;
    }
    
    public void printAllEmployee(SubCompanyManager sub){
        List list1 = sub.getAllEmployee();
        for(SubEmployee e:list1){
            System.out.println(e.getId());
        }

        List list2 = this.getAllEmployee();
        for(Employee e:list2){
            System.out.println(e.getId());
        }
    }
}

public class Client{
    public static void main(String[] args){
        CompanyManager e = new CompanyManager();
        e.printAllEmployee(new SubCompanyManager());
    }
}

现在这个设计的主要问题出在CompanyManager中，根据迪米特法则，只与直接的朋友发生通信，而SubEmployee类并不是CompanyManager类的直接朋友（以局部变量出现的耦合不属于直接朋友），从逻辑上讲总公司只与他的分公司耦合就行了，与分公司的员工并没有任何联系，这样设计显然是增加了不必要的耦合。按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。修改后的代码如下:

class SubCompanyManager{
    public List getAllEmployee(){
        List list = new ArrayList();
        for(int i=0; i<100; i++){
            SubEmployee emp = new SubEmployee();
            //为分公司人员按顺序分配一个ID
            emp.setId("分公司"+i);
            list.add(emp);
        }
        return list;
    }
    public void printEmployee(){
        List list = this.getAllEmployee();
        for(SubEmployee e:list){
            System.out.println(e.getId());
        }
    }
}

class CompanyManager{
    public List getAllEmployee(){
        List list = new ArrayList();
        for(int i=0; i<30; i++){
            Employee emp = new Employee();
            //为总公司人员按顺序分配一个ID
            emp.setId("总公司"+i);
            list.add(emp);
        }
        return list;
    }
    
    public void printAllEmployee(SubCompanyManager sub){
        sub.printEmployee();
        List list2 = this.getAllEmployee();
        for(Employee e:list2){
            System.out.println(e.getId());
        }
    }
}

这两个代码的区别，就是

打印子公司员工的信息的方法，放到了子公司类当中

总公司打印方法，传入子公司类即可

避免了总公司的打印方法操作子公司的员工信息，这就是所谓的不要和非直接朋友关系的类进行通信，

开闭原则-没有实际操作层面的原则，前面的原则执行好了自然就开闭了
【】定义：
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
【】问题由来：
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试
【】解决方案：
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化
【】理解：
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。开闭原则可能是设计模式六项原则中定义最模糊的一个了，它只告诉我们对扩展开放，对修改关闭，可是到底如何才能做到对扩展开放，对修改关闭，并没有明确的告诉我们。以前，如果有人告诉我“你进行设计的时候一定要遵守开闭原则”，我会觉的他什么都没说，但貌似又什么都说了。因为开闭原则真的太虚了。

三常见设计模式

把uml类图和设计模式的基本概念放在前面讲，是因为下面很多概念的类图说明会用到uml类图知识和设计模式知识，在学习六大原则和类图的过程中，也要一并将上面的知识进行融合消化理解，学习每个设计模式，尽量都要理解在uml类图解释他们的说明图和设计模式原则层面的知识！
我们很多伟大工作者为了将知识更方便的传播，将知识进行了分类传播，但是知识接收的过程中，如果要进行消化吸收，也必须获取到像知识传播者一样足够多的信息进行知识融合，才能够还原作者的意图，所以知识学习要逆传播过程，这个很像我们的osi 7层模型一样。

3.1 创建型模式

前面讲过，社会化的分工越来越细，自然在软件设计方面也是如此，因此对象的创建和对象的使用分开也就成为了必然趋势。因为对象的创建会消耗掉系统的很多资源，所以单独对对象的创建进行研究，从而能够高效地创建对象就是创建型模式要探讨的问题。这里有6个具体的创建型模式可供研究，它们分别是：
简单工厂模式（Simple Factory）
工厂方法模式（Factory Method）
抽象工厂模式（Abstract Factory）
创建者模式（Builder）
原型模式（Prototype）
单例模式（Singleton）
说明：严格来说，简单工厂模式不是GoF总结出来的23种设计模式之一