设计模式的六大设计原则

设计模式六大原则，具体如下：

单一职责原则（类和方法，接口）

开闭原则 （扩展开放，修改关闭）

里氏替换原则（基类和子类之间的关系）

依赖倒置原则（依赖抽象接口，而不是具体对象）

接口隔离原则（接口按照功能细分）

迪米特法则 （类与类之间的亲疏关系）

单一职责原则（类和方法，接口）

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
1、一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
2、当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的优点

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：

1. 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
2. 提高类的可读性。复杂性降低，自然其可读性会提高。
3. 提高系统的可维护性。可读性提高，那自然更容易维护了。
4. 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则的实现方法

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

public interface UserService {
    public void login(String username, String password);
    public void register(String email, String username, String password);
    public void logError(String msg);
    public void sendEmail(String email);
}

这段代码很显然存在很大的问题，UserService 既要负责用户的注册和登录，还要负责日志的记录和邮件的发送，并且后者的行为明显区别于前者。
假设我要修改发送邮件的逻辑就得修改这个类，这时候 qa 还得回归登录注册逻辑，这样明显不合理。

因此我们需要进行拆分，根据具体的职能可将其具体拆分如下：
UserService：只负责登录注册

public interface UserService {
    public void login(String username, String password);
    public void register(String email, String username, String password);
}

LogService ：只负责日志

public interface LogService {
    public void logError(String msg);
}

EmailService： 只负责发送邮件

public interface EmailService {
    public void sendEmail(String email);
}

这时候，咱们再去回顾前面提到的优点，就能深深体会了。
这里只是讲了接口，其实对类也一样，甚至方法也是一样的。
对于类来说，根据类名，确保里面提供的方法都是属于这个类的。
对于方法，不要把不相关的对象实例作为参数传进来。如果你发现某个方法依赖某个不相关的对象，那么这个方法的实现可能就存在问题。

比如 android 中图片下载后显示到 imageView 中，我提供如下的方法：

loadImage(String url, ImageView view) {
// 下载图片，展示图片
}

对于 loadImage 这个方法，参数 url 是ok 的，但是参数 ImageView 却是不合理的。因为这里做了两个操作，下载图片，展示图片。应该将这个方法在进行拆分：

// 下载图片 
loadImage(String url) {
}
// 显示图片
displayImage(String url, ImageView view) {
// 调用 getBitmap (url)  获取图片
// 获取图片后将其设置到 view 中。
}
// 根据 url 获取图片， 
getBitmap(String url) {
}

这样整个逻辑就很清晰。后续需要修改下载逻辑，也不会影响到展示逻辑。当然其实还有个问题是，这两个方法要不要放在一个类里面？