【设计模式笔记】（零） 设计模式六大原则

1.单一职责原则（Single Responsibility Principle，缩写SRP）

单一职责原则，就一个类而言，应该只有一个引发它变化的缘由。简单说，一个类应该是一组高度相关的函数、数据的封装；也就是高内聚。

下面代码为 ImageLoader（图片加载）类的代码

public class ImageLoader{
	//图片缓存
	LruCache<String,Bitmap> mImageCache;
	//线程池，线程数量为CPU的数量
	ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProessors());
	
	public ImageLoader(){
		initImageCache();
	}
	
	private void initImageCache() {
   		//省略...         
   }
    
   //显示图片
   public  void displayImage(final String url, final ImageView imageView) {
   		//省略... 
   }
    
   //下载图片
   public  Bitmap downloadImage(String imageUrl) {
        //省略... 
        return bitmap;
   }
}
复制代码

这里能够看出来 ImageLoader 类做用有初始化图片缓存、显示图片、下载图片，显然显示图片和下载图片两个方法与初始化图片缓存方法相比做用就显得有些不相关。也就是不符合单一职责原则。按照逻辑进行分拆以后获得ImageLoader和ImageCache两个类。ImageLoader负责图片加载逻辑，ImageCache负责处理图片缓存逻辑，这样职责就清楚了，当与缓存相关的逻辑须要改变时，不须要修改ImageLoader类，而图片加载的逻辑须要修改时也不会影响到缓存处理逻辑。

ImageLoader代码修改以下所示：

/** 图片加载类 */
public  class ImageLoader {
    //图片缓存
    ImageCache mImageCache = new ImageCache() ;
    //线程池,线程数量为CPU的数量
    ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.getRuntime().availableProcessors());

    //加载图片
    public  void displayImage(final String url, final ImageView imageView) {
        //省略... 
     }

    public  Bitmap downloadImage(String imageUrl) {
        //省略... 
        return bitmap;
    }
} 
复制代码

而添加的ImageCache类用于处理图片缓存，具体代码以下：

public class ImageCache {
    // 图片LRU缓存
    LruCache<String, Bitmap> mImageCache;

    public ImageCache() {
        initImageCache();
    }

    private void initImageCache() {
        //省略... 
    }

    public void put(String url, Bitmap bitmap) {
        mImageCache.put(url, bitmap) ;
    }

    public Bitmap get(String url) {
        return mImageCache.get(url) ;
    }
}
复制代码

如何划分一个类、一个函数的职责，每一个人都有本身的见解，这须要根据我的经验、具体的业务逻辑而定。

2.开闭原则（Open Close Principle，缩写OCP）

开闭原则是Java中最基础的设计原则，知道咱们如何创建一个稳定的、灵活的系统。定义：软件中得对象应该对于扩展是开放的，可是对于修改是封闭的。

例如图中MemonyCache、DiskCache、DoubleCache都实现了ImageCache接口，ImageLoader使用ImageCache处理缓存，就意味着ImageLoader能够经过setImageCache()指定使用哪种缓存类型，可使三种缓存其中任意一种，同时不须要修改ImageLoader中的代码。这也就是开闭原则的体现。

简单地说，当软件须要变化时，应该尽可能经过扩展的方式来实现变化，而不是经过修改已有的代码来实现。“应该尽可能”4个字说明OCP原则并非说绝对不能够修改原始类的，当代码须要须要重构的时候要及时重构，使代码恢复正常，而不是经过继承等方式添加新的实现，这会致使类型的膨胀以及历史遗留代码的冗余。

开发过程当中都没有那么理想的情况，所以，凡事也是须要结合具体状况再作决定，目的是更稳定、更灵活同时保有原有的正确性。

3.里氏替换原则（Liskov Substitution Principle，缩写LSP）

里氏替换原则，书上原话的定义简直看不得（解释的辣眼睛，彻底看不懂），简单地说就是全部引用基类的地方必须能透明地使用其子类的对象。只要父类能出现的地方子类就能够出现，并且替换为子类也不会产生任何错误或异常，使用者可能根本就不须要知道是父类仍是子类。可是，反过来就不行了，有子类出现的地方，父类未必就能适应。其实就是：抽象。

上图能够看出，Window依赖于View，而Button和TextView继承View。这里任何继承自View类的子类均可以设置给show()方法，也就是里氏替换原则。经过里氏替换，就能够自定义各式各样的View，而后传递给Window，而且将View显示到屏幕上。

里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，继承的优缺点都至关明

优势：

• 代码重用，减小建立类的成本，每一个子类都拥有父类的方法和属性
• 子类与父类基本类似，但又与父类有所区别
• 提升代码的可扩展性

缺点：

• 继承是侵入性的，只要继承就必须拥有父类的全部属性和方法
• 可能形成子类代码冗余、灵活性下降，由于子类必须拥有父类的属性和方法

事物老是具备两面性，如何权衡利与弊都是须要根据具体场景来作出选择并加以处理。

4.依赖倒置原则（Dependence Inversion Principle，缩写DIP）

依赖倒置原则，说的就是一种特定的就形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。依赖倒置原则的几个关键点：

• 高层模块不该该依赖低层模块，二者都应该依赖其抽象
• 抽象不该该依赖细节
• 细节应该依赖抽象

是否是以为和没说一个样，至少我是这么以为的；继续日后看才明白，所谓高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在 Java 语言中的表现就是：模块间的依赖经过抽象发生，实现类之间不发生直接的依赖关系，经过接口或抽象类产生依赖关系。什么是依赖关系呢？其实就是相互之间的调用关系。归纳来讲就是面向接口变成，或者是面向抽象编程。

其实依赖倒置原则主要目的就是解耦

依然可使用这张图来表示，表达出来就是ImageLoader和MemonyCache等并无直接关系，甚至ImageLoader只须要实现ImageCache类或继承其余已有的ImageCache子类完成相应的缓存功能，而后将具体的实现注入到ImageLoader便可实现缓存功能的替换。这也是依赖倒置原则的体现。

5.接口隔离原则（Interface Segregation Principle，缩写ISP）

接口隔离原则将很是庞大、臃肿的接口拆分红为更小的和更具体的接口；目的就是解耦。这个原则的作法和单一职责原则有点类似，就是说接口中得方法保持更高的相关性、尽可能少，避免掉不须要的方法。

举个栗子，如今有一个带有呼吸方法的接口，还有一个打鼾方法的接口；若是说，你把这两个方法放到一个接口中，基本就是违背接口隔离原则，毕竟呼吸和打鼾没有什么紧密的相关性；不可能说我须要呼吸的时候必定须要打鼾吧！

6.迪米特原则（Law of Principle，缩写LOP）

迪米特原则也称为最少知识原则（Least Knowledge Principle），定义：一个对象应该对其余对象有最少的了解。通俗地讲，一个类要对本身须要调用的类知道得最少，类的内部如何实现、如何复杂都与调用者（或依赖者）不要紧，调用者（或依赖者）只须要知道他须要的方法便可，其余的不须要关心。类与类之间的关系越密切，耦合度越大；当一个类发生改变时，对另外一个类的影响也越大。

迪米特法则还有一个英文解释是：Only talk to your immedate friends，翻译过来就是：只与直接的朋友通讯。什么叫作直接的朋友呢？每一个对象都必然会与其余对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系的类型有不少，例如组合、聚合、依赖等。

下图是Volley框架中的DiskBasedCache类（实现Cache接口）和Cache接口的代码

Volley中的Response缓存接口的设计。Cache接口定义了缓存类须要实现的最小接口，依赖缓存类的对象只须要知道这些接口便可。例如缓存的具体实现类DiskBasedCache，该缓存类将Response序列化到本地,这就须要操做File以及相关的类。

Volley的直接朋友就是DiskBasedCache，间接朋友就是mRootDirectory、mEntries等。Volley只须要直接和Cache类交互便可，并不须要知道File、mEntries等对象的存在。

文中有引用书本中得例子，也有根据本身理解举的例子，若有不对还望指出。