《Android源码设计模式》笔记

第1章-走向灵活软件之路-面向对象的六大原则

一、实现图片加载功能引出面向对象的原则
功能1：实现图片的获取，显示
1、将获取图片、显示图片的功能都写到一个类中；
优化：将获取图片、显示图片的功能单独抽出一个类；（优化代码的第一步，单一职责原则。）
功能2：在1的基础上，增加几种获取图片的方式
2、将获取图片的每一种方式都抽取作为一个类，提供put，set公共方法，修改显示图片的类的逻辑，通过new和if else来实现对几个获取图片的类的切换使用。
优化：new对象硬编码的方式不好测试，if else方式降低程序可读性、复杂度高，维护难。并且每次增加方式都要修改显示图片的类的逻辑，应该让遵循开闭原则，让程序更稳定、更灵活。因此，要面向接口编程，抽象一个获取图片的接口，提供put，set公共方法，遵循控制反转原则，通过依赖注入的方式，如提供set方法，将接口作为参数，降低对象间的耦合度，扩展性更强。

备注：
控制反转
控制反转（Inversion of Control，缩写为IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称DI），还有一种方式叫“依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。也可以说，依赖被注入到对象中。

技术分析：
因为大多数应用程序都是由两个或是更多的类通过彼此的合作来实现企业逻辑，Class A中用到了Class B的对象b，一般情况下，需要在A的代码中显式的new一个B的对象。
采用依赖注入技术之后，A的代码只需要定义一个私有的B对象，不需要直接new来获得这个对象，而是通过相关的容器控制程序来将B对象在外部new出来并注入到A类里的引用中。

依赖注入原理
具体的实现方式：
1、基于接口。实现特定接口以供外部容器注入所依赖类型的对象。
2、基于 set 方法。实现特定属性的public set方法，来让外部容器调用传入所依赖类型的对象。
3、基于构造函数。实现特定参数的构造函数，在新建对象时传入所依赖类型的对象。
4、基于注解。

问题汇总
1、参与者都有谁？
答：一般有三方参与者，一个是某个对象；一个是IoC/DI的容器；另一个是某个对象的外部资源。又要名词解释一下，某个对象指的就是任意的、普通的Java对象; IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序；对象的外部资源指的就是对象需要的，但是是从对象外部获取的，都统称资源，比如：对象需要的其它对象、或者是对象需要的文件资源等等。

2、依赖：谁依赖于谁？为什么会有依赖？
答：某个对象依赖于IoC/DI的容器。依赖是不可避免的，在一个项目中，各个类之间有各种各样的关系，不可能全部完全独立，这就形成了依赖。传统的开发是使用其他类时直接调用，这会形成强耦合，这是要避免的。依赖注入借用容器转移了被依赖对象实现解耦。

3、注入：谁注入于谁？到底注入什么？
答：通过容器向对象注入其所需要的外部资源

4、控制反转：谁控制谁？控制什么？为什么叫反转？
答：IoC/DI的容器控制对象，主要是控制对象实例的创建。反转是相对于正向而言的，那么什么算是正向的呢？考虑一下常规情况下的应用程序，如果要在A里面使用C，你会怎么做呢？当然是直接去创建C的对象，也就是说，是在A类中主动去获取所需要的外部资源C，这种情况被称为正向的。那么什么是反向呢？就是A类不再主动去获取C，而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中。

5、依赖注入和控制反转是同一概念吗？
答：从上面可以看出：依赖注入是从应用程序的角度在描述，可以把依赖注入描述完整点：应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，描述完整点：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。

总结：
上面的例子凸显了，单一职责、开闭原则的重要性。
依赖倒置原则可从横向的角度看，是针对依赖关系，进行解耦，依赖倒置其实也就是上面的控制反转。
里氏替换原则可从垂直的角度看，核心原理是抽象，抽象又依赖于继承这个特性，子类可扩展父类的方法，提高功能扩展性。
接口隔离原则，这个在文中对IO流的关闭的例子上可以看出，仅对关闭这个功能进行抽象，不仅使代码更简洁，同时也做到了隐藏了具体对象的细节，使系统耦合度更低。

第2章-应用最广的模式-单例模式

目的：资源的重复利用，提供加载速度
实现：
1、饿汉模式
2、懒汉模式
3、Double Check Lock(DCL)模式
4、静态内部类单例模式
5、枚举单例模式
6、容器单例模式

第3章-自由扩展你的项目-Builder模式

目的：允许客户端在不知道内部构建细节的情况下，可以更精细地控制对象的构造流程。
实现：
直接使用一个Builder来进行Product对象的组装，这个Builder为链式调用，他的每个setter方法都返回自身，最后一般提供一个create方法创建一个Product对象。

第4章-使程序运行更高效-原型模式

目的：多用于创建复杂的或者构造耗时的实例，因为这种情况下，拷贝一个已经存在的实例可使程序运行更高效。
实现：实现cloneable接口，重新clone方法，通过super.clone拷贝一个本身。（有浅拷贝和深拷贝，浅拷贝是引用原来的对象内容，会修改原始对象内容，而深拷贝不会）

第5章-应用最广泛的模式-工厂方法模式

第6章-创建型设计模式-抽象工厂模式

第7章-时势造英雄-策略模式

目的：实现一个功能可以有多种算法(或叫策略)，客户端需要知道所有策略，并选择一种注入到实现对象中，实现具体的功能。
(这个设计模式在前面六大原则的加载图片的实例有体现出来，获取图片的方式有多种，如从缓存中拿，从sd卡中拿，从网络中拿，客户端可从中选取一种注入到加载图片的实现对象中，实现具体的获取图片的功能)
实现：如上图，只需定义一个接口，定义一个抽象策略方法，不同的子类实现不同的策略。
然后用Context对象提供的set方法注入某一个策略对象即可。

第8章-随遇而安-状态模式

目的：控制一个对象内部的状态转换的条件表达式过于复杂时的情况，且客户端调用之前不需要了解具体状态。它把状态的判断逻辑转到表现不同状态的一系列类当中，可以把复杂的判断逻辑简化。维持开闭原则，方便维护。
实现：结构上与策略模式一致，区别是状态模式不需要客户端了解状态，而是有内部代码自动维护状态的切换和具体的行为，而策略模式需要客户端清楚所有的策略。
(另外，书中的wifi实例，也体现出了状态模式下，还能增加进行状态先后次序排列的功能，十分强大)

第9章-使编程更有灵活性-责任链模式

目的：
实现：

第10章-化繁为简的翻译机-解释器模式

目的：给定一个语言，定义它的语法，并定义一个解释器，这个解释器用于解析语言。
实现：
(其实AndroidManifest.xml就定义了，等标签（语句）的属性以及其子标签，规定了具体的使用（语法），通过PackageManagerService（解释器）进行解析。)

第11章-让程序畅通执行-命令模式