依賴反轉原則

依賴反轉原則

教室裡有學生要唸課文
最直接的想法是定義一個教室的類別
在教室裡面安排學生唸課文
非常的直覺

教室是高階組件
學生是低階組件
高階組件需要低階組件幫它完成任務

依賴的缺點

1. 耦合性高
   教室會高度依賴學生，學生簡直是為了教室而存在
2. 違反開放封閉原則
   要換另外一位學生，那你是一定要修改程式，這樣容易出錯

設計原則

依賴抽象，不要依賴具體類別

意思是解除高階組件對低階組件的依賴
兩者同時都要依賴抽象
但抽象到底是什麼

思考一下，我是老闆，我叫員工小明做事情
不是因為他小明他才幫我做事，因為他是員工

幾條方針

1. 盡量不保存物件的參考
2. 不應該從具體類別衍生
3. 任何方法不應該覆寫基底類別已經實作的方法

對於物件實例化的依賴

物件在類別裡面實例化，確實不好處理

思考你的物件是不是容易被更換
如果確定不可能更換，就不用太緊張

如果可能會改變，有幾個做法

1. 工廠模式
2. 依賴注入
3. 傳參數

Code

abstract class Student
{
    abstract public void readText();
}
class Jack extends Student{
    @Override
    public void readText() {
        System.out.println("jack say");
    }
}
class Jacy extends Student{
    @Override
    public void readText() {
        System.out.println("jacy say");
    }
}

class Howard {
    public void readText() {
        System.out.println("howard say");
    }
}
class ClassRoom{

    public void readText1(Student s){
        s.readText();
    }
    public void readText2(){
        Howard h = new Howard();
        h.readText();
    }
}

readText1:
ClassRoom依賴Student
低階組件也依賴Student
Student就是這邊的抽象

readText2:
ClassRoom依賴Howard

總結

反轉了一般人對物件導向的設計方式
一般都會由上往下的思考
這正是反轉了思考模式