这系列博文将先讲述七大设计模式的原则,再详述23种java设计模式。
博文皆是东拼西凑而成,若有错误,还望指出。
一、设计模式的目的
在代码编写的过程中,面临着代码耦合、内聚等问题,同时优质代码应该有很好的拓展性、复用性、可靠性、可读性(规范性)。设计模式包含了面向对象编程的精髓思想,使得代码呈现出
1)高内聚(相关度比较高的部分尽可能的集中,不要分散)
2)低耦合(模块之间尽可以能把依赖的部分降低到最小)
,同时也具有更好怕的代码复用性和可读性。
二、设计模式六大原则
SOLID+迪米特法则,最后额外加了一种
1)单一职责原则(Single-Resposibility Principle)
定义:A class should have a single responsibility, where a responsibility is nothing but a reason to change.(一个类应该有一个单一的职责,其中职责是唯一改变这个类的理由。)
含义:当设计某个模块的时候,我们应该留意,一个类最多为一类任务或者功能负责,并且当且仅当这类任务或者功能需要变动时,这个类才能发生变动。这样,类就会有高内聚特性。
比如,在设计一个员工类的时候,
public class Employee{
private String employeeId;
private String name;
private string address;
private Date dateOfJoining;
public boolean isPromotionDueThisYear(){
//promotion logic implementation
}
public Double calcIncomeTaxForCurrentYear(){
//income tax logic implementation
}
//Getters & Setters for all the private attributes
}
上面的Employee
类在逻辑上看起来正确。它具有员工所有的属性,如employeeId
,name
,age
,address
和dateOfJoining
。它甚至会告诉您该员工今年是否有资格晋升,并计算出该年度他必须支付的所得税。
但是,Employee
类违反了单一责任原则。让我们看看是怎么回事 –
- 确定员工是否应于今年晋升的逻辑实际上不是员工应承担的责任。公司的人力资源部门根据公司的人力资源政策(这可能每几年更改一次)承担此责任。在人力资源政策上的任何更改,都将需要更改Employee类。
- 同样,所得税的计算也不是员工的责任。财务部门负责处理当前的税收组成,该组成可能每年都会更新。如果员工类拥有所得税计算责任,那么每当税制计算方法发生变化时,都将需要更改员工类别。
- 最后,
Employee类
应承担维护员工核心属性的单一责任。
那么使用单一责任原则应该怎么做呢?
首先判断员工是否晋升应该是HR的工作,所以应该分开一个类
public class HRPromotions{
public boolean isPromotionDueThisYear(Employee emp){
//promotion logic implementation using the employee information passed
}
}
再者就是计算税收的财务类
public class FinITCalculations{
public Double calcIncomeTaxForCurrentYear(Employee emp){
//income tax logic implementation using the employee information passed
}
}
最后是Employee的核心属性类
public class Employee{
private String employeeId;
private String name;
private string address;
private Date dateOfJoining;
//Getters & Setters for all the private attributes
}
再举一个例子,比如设计商城用户类,用户拥有优惠券,用户类这样设计
public class User {
private String id;
private String name;
//more attributes
//获取用户优惠券
public List<Coupon> findUserCouponList(String id) {
//implements detail
}
}
从逻辑上来说,并没有错误,但是如果优惠券有变动的时候,比如更改优惠券类名,更改获取优惠券方式等等,那么User类也要随着更改,这就违反了单一职责原则。用户类应该只包含用户属性,优惠券功能应该由专门的类处理。
所以应该这样更改
用户类
public class User {
private String id;
private String name;
//more attributes
}
优惠券服务类
public class CouponServiceImplement {
//获取用户优惠券
public List<Coupon> findUserCouponList(String id) {
//implements detail
}
}