java 开发设计原则

单一职责原则

永远不要因为一个多余原因去改变类。

对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。

当我们做系统设计时，如果发现一个类有了两种职责，那就问自己一个问题：可以将这两个类分为两个类吗？ 如果真的有必要，那就分吧。避免一个类干的事情太多!

开放封闭原则

对扩展开放，对修改封闭，换句话说，可以去扩展类，但不要修改类

当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码，当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类把。

里氏替换原则

父类能够替换子类，但子类不一定能替换父类，也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。

在继承类是，务必重写（Override）父类中所有的方法，尤其要注意父类的protected方法（它们往往是让您重写的），子类尽量不要暴露自己的public方法 供外界调用。

最少知识原则

尽量减少对象之间的交互，从而减小类之间的耦合，简言之：低耦合，高内聚。

在做系统设计时，不要让一个类依赖于太多的其它类，需尽量减少依赖关系，否则，你死都不知道怎么死的。

接口隔离原则

不要对外暴露没有实际意义的接口，也就是说，接口是给别人调用的，那就不要去为难别人了， 尽可能保证接口的实用性，她好，我也好。

当需要对外暴露接口时，需要再三斟酌，对于接口，有些公司的保密性和安全性都有要求，如果真的没有必要对外提供的，就意味着，你将来要多做一件事情，何苦要给自己找事做呢。

依赖倒置原则

应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。

并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。

不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。

不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。

模块内部需要做到内聚度高，模块之间需要做到耦合度低。

尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。

在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。

将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。

模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。

不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。