1. 单一职责原则（Single Responsibility Principle）
单一职责原则
单一职责原则的定义就是：就一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。单一职责的划分界限并不总是那么清晰，经常需要靠个人经验而界定。
下面我们从一个例子对单一职责原则进行深入了解：刚入公司的小张由于还在开始熟悉业务，部门领导想对他的能力有一个大致的了解，遂选择让其写一个简单的ImageLoader图片加载库，要求可拓展，并且要求将图片缓存起来。
于是乎，经过查阅资料，忙碌的半天的小张终于将大致代码写了出来：
public class ImageLoader {
//线程池数量为CPU的数量
private ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
//图片缓存
private LruCache<String, Bitmap> mImageCache;
public ImageLoader() {
initImageCache();
}
private void initImageCache() {
//可使用的最大内存
int maxMerroy = (int) (Runtime.getRuntime().maxMemory() / 1024);
//取四分之一的可用内存作为缓存
int cacheSize = maxMerroy / 4;
mImageCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
}
};
}
public void displayImage(final ImageView imageView, final String url) {
Bitmap bitmap = mImageCache.get(url);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
imageView.setTag(url);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
private Bitmap downloadImage(String imageUrl) {
Bitmap bitmap;
try {
URL url = new URL(imageUrl);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(connection.getInputStream());
connection.disconnect();
return bitmap;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
满心欢喜的小张将上述代码拿给领导看时，领导居然说到：你这个类耦合性太高了，那可拓展性太低了，如果功能继续增加，是不是这个ImageLoader类将会越来越大呢？最后领导说道，你还是把ImageLoader拆分一下，把各个功能独立拆分开来，让它们满足单一职责原则。小张听到了关键词“单一职责原则”，于是乎小张又一次紧锣密鼓…..最后小张修改的结果如下，将原先的ImageLoader按功能拆分成ImageLoader和MemoryCache：
ImageLoader：
public class ImageLoader {
//线程池数量为CPU的数量
private ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
//图片缓存
private MemoryCache mImageCache = new MemoryCache();
public void displayImage(final ImageView imageView, final String url) {
Bitmap bitmap = mImageCache.get(url);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
imageView.setTag(url);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
private Bitmap downloadImage(String imageUrl) {
Bitmap bitmap;
try {
URL url = new URL(imageUrl);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(connection.getInputStream());
connection.disconnect();
return bitmap;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
MemoryCache：
public class MemoryCache{
private LruCache<String, Bitmap> mMemoryCache;
public MemoryCache() {
initMemoryCache();
}
private void initMemoryCache() {
//可使用的最大内存
int maxMerroy = (int) (Runtime.getRuntime().maxMemory() / 1024);
//取四分之一的可用内存作为缓存
int cacheSize = maxMerroy / 4;
mImageCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
}
};
}
public void put(String url, Bitmap bitmap) {
mMemoryCache.put(url, bitmap);
}
public Bitmap get(String url) {
return mMemoryCache.get(url);
}
}
看完这些，有人可能要说了，这不就是将一个类分成两个类嘛，这有什么可说的呢！其实不然，这不只是两个类这么简单，我们仔细来看这两个类，ImageLoader只负责图片加载的逻辑，MemoryCache只负责图片缓存的逻辑，这样ImageLoader的代码量变少了，职责也清晰了；当与缓存相关的逻辑需要改变时，不需要修改MemoryCache类，而图片加载的逻辑修改也不需要修改ImageCache类。
从上述的例子中我们可以看出，单一职责的用意就是“单一”二字。正如上文所说，如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体的业务逻辑而定。但是它也有一些基本的指导原则，例如，两个完全不一样的功能就不应该放在一个类中。一个类中应该是一组相关性很高的函数、数据的封装。工程师可以不断地审视自己的代码，根据不同的功能、业务对类进行相应的划分，这是程序员优化代码迈出的第一步。
2. 依赖倒置原则（Dependence Inversion Principle）
依赖倒置原则
依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
依赖倒置原则有以下几个关键点：
（1）高层次模块不应该依赖低层次模块，两者都应该依赖其抽象；
（2）抽象不应该依赖细节；
（3）细节应该抽象。
在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或者继承抽象类而产生的类就是细节，其特点就是可以直接被实例化，也就是可以加上一个关键字new产生一个对象。高层次模块就是调用端，低层次模块就是具体实现类。
来让我们再看看上面的这个例子，ImageLoader直接依赖于MemoryCache，这个MemoryCache是一个具体实现，而不是一个抽象类或者接口。这导致了ImageLoader直接依赖了具体细节，当MemoryCache不能满足ImageLoader而需要被其它缓存实现替换时，此时就必须修改ImageLoader的代码。为了让缓存系统更加灵活，依赖抽象，而不依赖于具体实现，我们新建一个接口类，提供相应的put、get方法，同时让所有的缓存类都实现这个接口类，在ImageLoader中通过依赖注入的方式，从而保证了系统的灵活性。废话不多说，直接上代码：
ImageCache：
public interface ImageCache {
Bitmap get(String url);
void put(String url, Bitmap bitmap);
}
MemoryCache：
public class MemoryCache implements ImageCache {
private LruCache<String, Bitmap> mMemoryCache;
MemoryCache() {
initImageCache();
}
private void initImageCache() {
//可使用的最大内存
int maxMerroy = (int) (Runtime.getRuntime().maxMemory() / 1024);
//取四分之一的可用内存作为缓存
int cacheSize = maxMerroy / 4;
mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getRowBytes() * bitmap.getHeight() / 1024;
}
};
}
@Override
public Bitmap get(String url) {
return mMemoryCache.get(url);
}
@Override
public void put(String url, Bitmap bitmap) {
mMemoryCache.put(url, bitmap);
}
}
DiskCache：
public class DiskCache implements ImageCache {
private String cacheDir = "sdcard/cache/";
//从缓存中获取图片
@Override
public Bitmap get(String url) {
return BitmapFactory.decodeFile(cacheDir + url);
}
//将图片缓存到内存中
@Override
public void put(String url, Bitmap bitmap) {
FileOutputStream fileOutputStream = null;
try {
fileOutputStream = new FileOutputStream(cacheDir + url);
bitmap.compress(Bitmap.CompressFormat.PNG, 100, fileOutputStream);
} catch (FileNotFoundException e) {
e.printStackTrace();
} finally {
if (fileOutputStream != null) {
try {
fileOutputStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}
DoubleCache ：
public class DoubleCache implements ImageCache {
MemoryCache memoryCache = new MemoryCache();
DiskCache diskCache = new DiskCache();
//先从内存中获取图片，获取不到才去sd卡中获取图片
@Override
public Bitmap get(String url) {
Bitmap bitmap = memoryCache.get(url);
if (bitmap == null) {
bitmap = diskCache.get(url);
}
return bitmap;
}
@Override
public void put(String url, Bitmap bitmap) {
memoryCache.put(url, bitmap);
diskCache.put(url, bitmap);
}
}
最后让我们来看看ImageLoader类：
public class ImageLoader {
//线程池数量为CPU的数量
private ExecutorService mExecutorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
//图片缓存
private ImageCache mImageCache = new MemoryCache();
public void displayImage(final ImageView imageView, final String url) {
Bitmap bitmap = mImageCache.get(url);
if (bitmap != null) {
imageView.setImageBitmap(bitmap);
return;
}
imageView.setTag(url);
mExecutorService.submit(new Runnable() {
@Override
public void run() {
Bitmap bitmap = downloadImage(url);
if (bitmap == null) {
return;
}
if (imageView.getTag().equals(url)) {
imageView.setImageBitmap(bitmap);
}
mImageCache.put(url, bitmap);
}
});
}
private Bitmap downloadImage(String imageUrl) {
Bitmap bitmap;
try {
URL url = new URL(imageUrl);
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
bitmap = BitmapFactory.decodeStream(connection.getInputStream());
connection.disconnect();
return bitmap;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
public void setImageCache(ImageCache imageCache) {
this.mImageCache = imageCache;
}
}
在这里，我们建立了ImageCache抽象，并且让ImageLoader依赖于抽象而不是具体细节。当需求发生变化时，只需要实现ImageCache接口就可以完成缓存功能，然后将具体的实现注入到ImageLoader即可实现缓存功能的替换，这就保证了缓存系统的高可扩展性，有了拥抱变化的能力，这就是依赖倒置原则。
3. 开闭原则（Open Close Principle）
开闭原则
开闭原则是Java中最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，而对于修改是关闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引进原本已经经过测试的旧代码中，破坏原有系。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改原有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景。因此，在实际的开发中，修改原有代码、扩展代码往往是同时存在的。
就拿上面的例子来说，开始的时候ImageLoade严重依赖于MemoryCache的实现，这就导致只要用户提出需要缓存SD卡，就需要修改ImageLoader，这显示是不符合开闭原则的，故而上述改变的做法符合开闭原则，当需求有变化时，只需要利用现有的类或者再创建一个实现于ImageCache的缓存类即可，无需变更ImageLoader的具体实现。开闭原则的宗旨就是对扩展开放，而对修改关闭。
4. 接口隔离原则（Interface Segregation Principle）
接口隔离原则
接口隔离原则的定义是：客户端不应该依赖它不需要的接口。另一种定义就是类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小、更具体的接口。这样客户只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
我们可以把两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗的讲就是，接口尽量细化，接口中的方法尽可能的少。如我们经常写的MVP，有时候我们可以依赖这个原则去建立我们的接口，让某一个模块或者说是某一个功能提供单独的接口，而不是所有的方法都放在一个接口中，这样在复用的时候就可以复用这个专门的接口，而不是复用一个很臃肿的接口，因为这样你还会重写其中的不必要的方法。
5. 里式替换原则（Liskov Substitution Principle）
里式替换
第一个定义，也是最正宗的定义：If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T，the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.
如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
第二个定义：functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能够透明地使用其子类的对象。
第二个定义是最清晰明确的，通俗点讲只要父类能出现的地方我子类就可以出现，而且调用子类还不能产生任何的错误或异常，调用者可能根本就不需要知道是父类还是子类。但是反过来就不成了，有子类出现的地方，父类未必就能适应。
最近有一款游戏《绝地求生》很火，内容就是角色扮演成军人，然后寻找各种枪支装备，并杀死敌人，最终吃鸡，接下来让我们以这个游戏为切入点来来看看里式替换原则的具体体现：
抽象类AbstractGun：
public abstract class AbstractGun {
public abstract void shoot();
}
HandGun：
public class HandGun extends AbstractGun {
@Override
public void shoot() {
System.out.println("手抢射击...");
}
}
Rifle：
public class Rifle extends AbstractGun {
@Override
public void shoot() {
System.out.println("步枪射击...");
}
}
MachineGun：
public class MachineGun extends AbstractGun {
@Override
public void shoot() {
System.out.println("机枪扫射...");
}
}
Solider：
public class Solider {
public void killEnemy(AbstractGun gun) {
if (gun != null) {
gun.shoot();
}
}
}
注意看这里，我们要求传入进来的是AbstractGun，抽象的枪，具体是手枪、步枪还是机枪，我们还需要在调用的时候传入。
客户端Client调用：
public class Client {
public static void main(String[] args) {
Solider solider = new Solider();
solider.killEnemy(new Rifle());
}
}
Solider根本就无需知道是哪个子类，我们在类中调用其它类是务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
里式替换原则的核心原理是抽象，抽象又依赖于继承这个特性。
6. 迪米特原则（Law of Demeter）
迪米特原则
迪米特原则，也称为最少知识原则（Least Knowledge Principle）。意思都是，一个对象应该对其他对象有最少的了解。通俗地将，一个类应该对自己需要耦合或调用的类知道得最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其它的可一概不用管。
总结
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了各个版本的变更之后依然保持清晰、灵活、稳定的系统架构。当然，这是一个比较理想的情况，但我们必须要朝着这个方向去努力，那么遵循面向对象的六大原则就是我们走向灵活软件之路迈出的第一步。
喜欢本篇博客的简友们，就请来一波点赞，您的每一次关注，将成为我前进的动力，谢谢！作者：zhang_pan
