软件设计五大原则的初认识

每天都在写代码，可是我们真的思考代码中的这些设计原则吗？下面我就一些常用的设计原则，做个分享：

1. 开闭原则
软件实体如：class对修改关闭，对拓展开放。抽象构建框架，实现拓展细节。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简单来说：就是为了使程序的扩展性好，易于维护和升级。

2. 依赖倒置原则
上层模块不应该依赖底层模块，它们都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
举例：三层架构

service（高层） -> dao（低层）
service的实现类不应该直接依赖于dao的实现类，而是应该依赖dao的接口。这样做的好处就是在不需要修改service实现类和dao实现类的情况下，对dao的实现类进行拓展，符合开闭原则。service实现类和dao实现类是解耦合的，但service实现类和dao接口是低耦合的，符合高内聚低耦合。

举例：
service实现类中的dao本来使用jdbc实现，现在需要使用hibernate实现。我们就可以在保留原来jdbc实现的dao，通过拓展dao接口的方式，开发hibernate实现的dao。

service实现
public class UserServiceImpl {
    private UserDao userDao;
    public List<User> getUserList() {
        return userDao.findAll();
    }
}
使用hibernate实现的dao
public class userDaoHibernateImpl {
    public User findAll() {
        // ...
    }
}
使用jdbc实现的dao
public class userDaoJdbcImpl {
    public User findAll() {
        // jdbc...
    }
}

3. 单一职责原则

一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。适用于类、接口、方法等，减少复杂度、提高可读性和可维护性。

4. 接口隔离原则
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
高内聚低耦合：高内聚要求减少对外交互，使接口中最少的方法去完成最多的事情。低耦合要求降低依赖关系。

5. 迪米特原则
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
朋友圈的确定
“朋友”条件：
1）当前对象本身（this）
2）以参量形式传入到当前对象方法中的对象
3）当前对象的实例变量直接引用的对象
4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友
5）当前对象所创建的对象
任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”；否则就是“陌生人”。
狭义的迪米特法则的缺点：
在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的业务逻辑无关。
遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。
门面模式和调停者模式（中介者模式）实际上就是迪米特法则的应用。
广义的迪米特法则在类的设计上的体现：
优先考虑将一个类设置成不变类。
尽量降低一个类的访问权限。
谨慎使用Serializable。
尽量降低成员的访问权限。