《Android源码设计模式解析与实战》读书笔记1.面向对象的六大原则

走向灵活软件之路——面向对象的六大原则

1. 优化代码的第一步——单一职责原则

Single Responsibility Principle，缩写是SRP，定义：就一个类而言，应该仅有一个引起它变化的原因。
简单来说，一个类中应该是一组相关性很高的函数、数据的封装，两个完全不一样的功能就不应该放在一个类中。
实例：

将ImageLoader一拆为二，ImageLoader只负责图片加载的逻辑，而ImageCache只负责处理图片缓存的逻辑，这样ImageLoader的代码量变少了，职责也清晰了；当与缓存相关的逻辑需要改变时，不需要修改ImageLoader类，而图片加载的逻辑需要修改时也不会影响到缓存处理逻辑。

2. 让程序更稳定、更灵活——开闭原则

Open Close Principle，缩写是OCP，定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。
实例：
通过内存缓存图片存有不足，引入SD卡缓存。新增了一个DiskCache类和往ImageLoader类中加入了少量代码就添加了SD卡缓存的功能，用户可以通过useDiskCache方法来对使用哪种缓存进行设置。
仍有明显问题，两种缓存策略只能选其一。新建双缓存类DoubleCache。这样每次加新的缓存方法时都要修改原来的代码，这样很可能会引入Bug，而且会使原来的代码逻辑变得原来越复杂，而且用户也不能自定义缓存实现，可扩展性差。

重构后，ImageCache类被提取成一个图片缓存的接口，用来抽象图片缓存的功能。ImageLoader类中增加setImageCache(ImageCache cache)函数，用户可以通过该函数设置缓存实现，也就是依赖注入，这样不仅使ImageLoader更简单、健壮，也使得其可扩展性、灵活性更高。MemoryCache、DiskCache、DoubleCache缓存图片的具体实现完全不一样，但是它们都实现了ImageCahce接口。当用户需要自定义实现缓存策略时，只需要新建一个实现ImageCache接口的类，然后构造该类的对象，并且通过setImage(ImageCache cache)注入到ImageLoader中，这样ImageLoader就实现了千变万化的缓存策略，且扩展这些缓存策略并不会导致ImageLoader类的修改。
（待续……）