有幾天沒發文章了，一直有人在公眾號問我關于觀察者模式的問題，所以我決定抽時間寫一寫關于設計模式的內容。今天先介紹一些基礎的東西。
六大原則
我以前在面試別的人的時候，總是喜歡聊聊設計模式，因為總感覺功能部分都能寫出來，但是代碼質量和代碼設計的東西熟練，才能更好地跟團隊配合，方便產品的迭代。
六大原則是：
- 單一職責原則
- 里氏替換原則
- 依賴倒置原則
- 接口隔離原則
- 迪米特原則
- 開閉原則
也有人說是五大原則的，少了迪米特原則。乍一看，其中開發者們最熟悉的或者說聽得最多的也就是開閉原則了，其它聽起來都會有一些陌生。下面就一個個介紹一下。
單一職責原則
這是一個最簡單，卻最難做到的原則。為什么這么說呢?
它的定義只有一句話：不要存在多于一個導致類變更的原因。通俗的說，即一個類只負責一項職責。但為什么說很難做到呢，我剛才想去我的代碼中找到一個比較合適的例子來說明這個問題，卻沒有一個具有代表性的，因為職責這個概念有些主觀，接口根據職責劃分。下面想個簡單的例子吧。
例如一個用戶系統，有姓名和年齡兩個屬性：
public class Person {
private String name;
private String age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
public void changeAge(String age) {
}
public void changeName(String age) {
}
}
這個類建立有什么問題呢？name和age的set，get方法是數據類型，也就是業務對象，但是changeAge和changeName需要跟服務器進行交互，屬于業務邏輯，甚至于在這兩個方法中還需要調用set，get方法。
根據單一職責原則，我們需要將業務和數據分開：
public class PersonObj {
private String name;
private String age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getAge() {
return age;
}
public void setAge(String age) {
this.age = age;
}
}
public class PersonLogic {
public void changeAge(String age) {
}
public void changeName(String age) {
}
}
單一原則的好處：
- 可以降低類的復雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
- 提高類的可讀性，提高系統的可維護性；
- 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。
里氏替換原則
定義1：如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發生變化，那么類型 T2 是類型 T1 的子類型。
定義2：所有引用基類的地方必須能透明地使用其子類的對象。
根據定義我們可以這樣理解：
- 子類必須完全實現父類的方法
- 子類可以有自己的個性
- 覆寫或實現父類的方法時輸入參數可以寬于或等于父類參數
- 覆寫或實現父類的方法時輸出結果可以窄于或等于父類參數
第一點好理解，后面是什么意思呢？看個例子：
public class Father {
public void printf(HashMap map){
System.out.printf("父類方法");
}
}
public class Son {
public void printf(Map map){
System.out.printf("父類方法");
}
}
這樣只要傳入的參數是HashMap都是執行父類的方法，子類由于比父類參數要寬，相當于重載了printf方法。這樣做的目的不容易引起邏輯的混亂
依賴導致原則
定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
依賴倒置原則的核心思想是面向接口編程，我們依舊用一個例子來說明面向接口編程比相對于面向實現編程好在什么地方。場景是這樣的，父親給孩子講故事，需要給他一本書，或一份報紙：
class Book{
public String getContent(){
return "讀書";
}
}
class NewsPaper{
public String getContent(){
return "報紙";
}
}
class Father{
public void read(Book book){
System.out.println("爸爸"+book.getContent());
}
public void read(NewsPaper news){
System.out.println("爸爸"+news.getContent());
}
}
public class Client{
public static void main(String[] args){
Father f = new Father();
f.read(new Book());
f.read(new NewsPaper());
}
}
上述代碼沒有什么問題，但是有一天我們再新增一個可讀的東西，如pad，那我們要重新寫一個pad類，同時Father類還要新增一個read方法。如果哪天再增加一個類，還有做如上處理，太麻煩了。
我們可以這樣優化一下：
interface IReader{
public String getContent();
}
然后讓Book Newspaper Pad類都實現這個接口，這樣父類只需要寫一個方法即可：
class Father{
public void read(IReader reader){
System.out.println("爸爸"+reader.getContent());
}
}
接口隔離原則
定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
簡單翻譯一下這句話，就是一個類去實現接口的時候，不應該去實現他不需要的方法。
interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}
class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}
class B implements I{
public void method1() {
System.out.println("類B實現接口I的方法1");
}
public void method2() {
System.out.println("類B實現接口I的方法2");
}
public void method3() {
System.out.println("類B實現接口I的方法3");
}
public void method4() {}
public void method5() {}
}
class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}
class D implements I{
public void method1() {
System.out.println("類D實現接口I的方法1");
}
//對于類D來說，method2和method3不是必需的，但是由于接口A中有這兩個方法，
//所以在實現過程中即使這兩個方法的方法體為空，也要將這兩個沒有作用的方法進行實現。
public void method2() {}
public void method3() {}
public void method4() {
System.out.println("類D實現接口I的方法4");
}
public void method5() {
System.out.println("類D實現接口I的方法5");
}
}
public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
}
可以看到，如果接口過于臃腫，只要接口中出現的方法，不管對依賴于它的類有沒有用處，實現類中都必須去實現這些方法，這顯然不是好的設計。如果將這個設計修改為符合接口隔離原則，就必須對接口I進行拆分。在這里我們將原有的接口I拆分為三個接口。
nterface I1 {
public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
public void method5();
}
class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}
class B implements I1, I2{
public void method1() {
System.out.println("類B實現接口I1的方法1");
}
public void method2() {
System.out.println("類B實現接口I2的方法2");
}
public void method3() {
System.out.println("類B實現接口I2的方法3");
}
}
class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}
class D implements I1, I3{
public void method1() {
System.out.println("類D實現接口I1的方法1");
}
public void method4() {
System.out.println("類D實現接口I3的方法4");
}
public void method5() {
System.out.println("類D實現接口I3的方法5");
}
}
接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。也就是說，我們要為各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。本
迪米特法則
定義：一個對象應該對其他對象保持最少的了解。
說白點就是盡量降低耦合。
我在網上找到了這樣一個簡單例子，可以看一下，做個對比：
有一個集團公司，下屬單位有分公司和直屬部門，現在要求打印出所有下屬單位的員工ID。先來看一下違反迪米特法則的設計。
//總公司員工
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
//分公司員工
class SubEmployee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//為分公司人員按順序分配一個ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
}
class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//為總公司人員按順序分配一個ID
emp.setId("總公司"+i);
list.add(emp);
}
return list;
}
public void printAllEmployee(SubCompanyManager sub){
List<SubEmployee> list1 = sub.getAllEmployee();
for(SubEmployee e:list1){
System.out.println(e.getId());
}
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}
public class Client{
public static void main(String[] args){
CompanyManager e = new CompanyManager();
e.printAllEmployee(new SubCompanyManager());
}
}
現在這個設計的主要問題出在CompanyManager中，根據迪米特法則，只與直接的朋友發生通信，而SubEmployee類并不是CompanyManager類的直接朋友（以局部變量出現的耦合不屬于直接朋友），從邏輯上講總公司只與他的分公司耦合就行了，與分公司的員工并沒有任何聯系，這樣設計顯然是增加了不必要的耦合。按照迪米特法則，應該避免類中出現這樣非直接朋友關系的耦合。修改后的代碼如下:
class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//為分公司人員按順序分配一個ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
public void printEmployee(){
List<SubEmployee> list = this.getAllEmployee();
for(SubEmployee e:list){
System.out.println(e.getId());
}
}
}
class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//為總公司人員按順序分配一個ID
emp.setId("總公司"+i);
list.add(emp);
}
return list;
}
public void printAllEmployee(SubCompanyManager sub){
sub.printEmployee();
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}
修改后，為分公司增加了打印人員ID的方法，總公司直接調用來打印，從而避免了與分公司的員工發生耦合。
開閉原則
這應該是我們聽得最多的一個原則了，在平時的項目開發中，用的也最多，因為誰也不想，一次產品的迭代，還需要修改核心代碼，然后全部重新測試一次。
定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
這個定義沒有那么復雜難理解，我不再做過多的解釋，我這里還是通過一個小例子來說明：
public interface ICar {
public String getName();
public float getPrice();
}
public class Car implements ICar{
private String name;
private float price;
public Car(String name,float price){
this.name = name;
this.price = price;
}
@Override
public String getName() {
return name;
}
@Override
public float getPrice() {
return price;
}
}
當有一天我們獲取車的價格需要打折時，可以重新寫一個類SaleCar：
public class SaleCar extends Car{
public SaleCar(String name, float price) {
super(name, price);
}
@Override
public float getPrice() {
return super.getPrice()*8/10;
}
}
我們這樣做的目的是當有新功能出現的時候，盡量不要去修改原有的邏輯，可以實現一個新的類，然后覆寫父類的方法，這樣，原有的邏輯沒有變，新的需求也實現了。當有一天出現bug了，可以直接修改這一個類就可以。
