java 开发几个设计原则；

java 开发几个设计原则；

1单一职责原则【Single Responsibility Principle】

单一职责原则：应该有且仅有一个原因引起类的变更

那使用了单一职责原则有什么好处呢？
类的复杂性降低，实现什么职责都有清晰明确的定义；
可读性提高，复杂性降低，那当然可读性提高了；
可维护性提高，那当然了，可读性提高，那当然更容易维护了；
变更引起的风险降低

 

单一职责即一个方法尽可能做一件事情，比如一个方
法修改用户密码，别把这个方法放到“修改用户信息”方法中，这个方法的颗粒度很粗，比如这个一个方
法：
IUserManager
<<interface>>
+public void changeUser(IUserBO userBO, int type, String...changeOptions)
在IUserManager 中定义了一个方法叫changeUser，根据传递的type 不同，把可变长度参数changeOptions 修改到userBo 这个对象上，并调用持久层的方法保存到数据库中。这个接口设计得很糟糕

现在修改如下：

IUserManager
<<interface>>
+public void changeUserName(String newUserName)
+public void changeHomeAddress(String newHomeAddress)
+public void changeOfficeTel(String telNumber)
你要修改用户名称，就调用changeUserName 方法，你要修改家庭地址就调用changeHomeAddress，你
要修改单位单户就调用changeOfficeTel 方法，每个方法的职责就非常清晰，这也是一个良好的设计习惯。

 

2 里氏替换原则【Liskov Substitution Principle】

定义functions that use pointers or references to base classes must be able to use
objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象。

要求

A子类必须完全的实现父类的方法

B子类可以有自己的个性

C覆盖或实现父类的方法时输入参数可以被放大

D覆盖或实现父类的方法是输出结果可以被缩小

3迪米特法则

迪米特法则也叫做做最少知识原则（Least
Knowledge Principle，简称LKP

A只和朋友交流

朋友即出现在成员变量、方法的输入输出参数中的类被称为成员朋友类，

但是朋友也是有距离的，不能把自己暴露得太多给自己的朋友

B自己的就是自己的。在项目中有一些方法，放在本类中也可以，放在其他类中也没有错误，那怎么
去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，即不增加类间关系，也对本类不产生负
面影响，就放置在本类中。

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求
的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，你项
目管理就复杂。