設計模式——物件導向設計原則

物件導向設計原則

都是為了高內聚低耦合原則。程式設計時基本都要遵守

單一職責原則

分類原則：一種人只幹一種事。

舉例：（比較簡單就不程式碼了）

人可以乾的事情有很多：敲程式碼、唱歌、跳舞、打籃球....以人設定成一個類，裡面的方法就太多太雜了。所以可以有多個類：程式設計師（敲程式碼）、音樂人（唱歌）、愛豆（跳舞）、NBA球員（打籃球）。這樣類就具體化了，可以乾的事情也就具體了，一旦需要用哪個方法就知道從哪個類裡呼叫了。

開閉原則

開：提供方提供 抽象類/介面/方法等，實現類可以決定行為。閉：呼叫方呼叫時，儘量不需要修改程式碼。

定義：一個軟體實體，比如類、模組和函數應該對擴充套件開放，對修改關閉。其中，對擴充套件開放是針對提供方來說的，對修改關閉是針對呼叫方來說的。

舉例：

//介面
public interface AccountService {
    //實現註冊賬戶
    void createAccount(String username,String password,String email);

}

//實現類
public class AccountServiceImpl implements AccountService {
        public void createAccount(String username,String password,String email) {
            ....
        }
}

里氏替換原則

對子類的特別定義：父類別方法非抽象方法，子類不可以過載（覆蓋）。但如果父類別有抽象方法則子類必須實現父類別的抽象方法，子類也可以編寫自己的方法

里氏替換原則（Liskov Substitution Principle）是對子型別的特別定義。所有參照基礎類別的地方必須能透明地使用其子類的物件。

白話：子類可以擴充套件父類別的功能，但不能改變父類別原有的功能。有以下四原則：（重點在一二）

子類可以實現父類別的抽象方法，但不能覆蓋父類別的非抽象方法。
子類可以增加自己特有的方法。
當子類的方法過載父類別的方法時，方法的前置條件（即方法的輸入/入參）要比父類別方法的輸入引數更寬鬆。
當子類的方法實現父類別的方法時（重寫/過載或實現抽象方法），方法的後置條件（即方法的輸出/返回值）要比父類別更嚴格或與父類別一樣。

如：子類繼承了父類別，但沒有修改父類別的非抽象方法

public abstract class Coder {
     public abstract void eat();   //這個行為還是定義出來，但是不實現

    public void coding() {
        System.out.println("我會打程式碼");
    }


    class JavaCoder extends Coder{
        public void game(){		//子類自己的額外的方法
            System.out.println("艾歐尼亞最強王者已上號");
        }
        
        public void eat(){	//子類實現父類別的抽象方法（必須）
            System.out.println("幹啥啥不行，乾飯第一名！")
        }
    }
}

依賴倒轉原則

使用Spring註解注入介面，這樣需求更改後實現類可以自由編寫，不會影響到controller層（將每一層都分隔開來降低耦合性）

定義：高層模組不應依賴於底層模組，它們都應該依賴抽象。抽象不應依賴於細節，細節應該依賴於抽象。

傳統：沒有介面而是類與類之間的物件建立。一旦需求變化，類就需要重寫，這樣其他類也需要修改

public class Main {

    public static void main(String[] args) {
        UserController controller = new UserController();
    }

    static class UserMapper {
        //CRUD...
    }

    static class UserServiceNew {   //由於UserServiceNew發生變化，會直接影響到其他高層模組
        UserMapper mapper = new UserMapper();
        //業務程式碼....
    }

    static class UserController {   //焯，幹嘛改底層啊，我這又得重寫了
        UserService service = new UserService();   //哦豁，原來的不能用了
        UserServiceNew serviceNew = new UserServiceNew();   //只能修改成新的了
        //業務程式碼....
    }
}

Spring框架：使用註解注入介面bean，這樣實現類可隨便改，只要最後的實現類實現了該介面即可

//controller
public class LoginApiController {
    @Autowired	//Spring註解注入介面bean
    private VerifyService verifyService;

    @GetMapping("/verify-code")
    public RestBean<Void> verifyCode(@RequestParam("email") String email) {
        try {
            verifyService.sendVerifyCode(email);
            return new RestBean<>(200, "郵箱傳送成功!");
        } catch (Exception e) {
            return new RestBean<>(500, "郵箱傳送失敗!");
        }
    }
}

介面隔離原則

對介面進行細分，避免介面中定義的方法，在實現類中用不上。

舉例：定義一個介面，有方法：裝置晶片、裝置名稱、裝置記憶體。這樣的介面只有電腦、手機等實現類才可以實現，而對於風扇、檯燈等普通裝置實現類而言確只有裝置名稱才是有效的方法。於是就需要把介面進行細化成兩個介面。

interface SmartDevice {   //智慧裝置才有getCpu和getMemory
    String getCpu();
    String getType();
    String getMemory();
}

interface NormalDevice {   //普通裝置只有getType
    String getType();
}

//電腦就是一種電子裝置，那麼我們就繼承此介面
class Computer implements SmartDevice {

    @Override
    public String getCpu() {
        return "i9-12900K";
    }

    @Override
    public String getType() {
        return "電腦";
    }

    @Override
    public String getMemory() {
        return "32G DDR5";
    }
}

//電風扇也算是一種電子裝置
class Fan implements NormalDevice {
    @Override
    public String getType() {
        return "風扇";
    }
}

合成複用原則

優先使用物件組合，而不是通過繼承來達到複用的目的。

合成複用原則（Composite Reuse Principle）的核心就是委派。

情況：如果A類裡寫了想要的方法，為了不在B類不重複編寫程式碼，可以在B類中設定一個方法：將A類的物件作為引數並在設定的方法裡通過物件獲取到A類中想要的方法。【此時不建議使用繼承，因為容易引起安全隱患，如：A中有一下資訊(密碼欄位)不方便傳遞】

舉例：

class A {
    public void connectDatabase(){
        System.out.println("我是連線資料庫操作！");
    }
}

class B {
    
    A a;
    public B(A a){   //在構造時就指定好
        this.a = a;
    }
    
    public void test(){
        System.out.println("我是B的方法，我也需要連線資料庫！");
        a.connectDatabase();   //也是通過物件A去執行
    }
}

迪米特法則

每一個軟體單位對其他單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟體單位。

迪米特法則（Law of Demeter）又稱最少知識原則，是對程式內部資料互動的限制。

簡單來說就是，一個類/模組對其他的類/模組有越少的互動越好。當一個類發生改動，那麼，與其相關的類（比如用到此類啥方法的類）需要儘可能少的受影響（比如修改了方法名、欄位名等，可能其他用到這些方法或是欄位的類也需要跟著修改）這樣我們在維護專案的時候會更加輕鬆一些。

白話：在設計方法引數的時候，保證不多給方法多餘的引數。例如：方法只需要一個使用者的ip地址就可以執行，方法引數就不要寫成需要輸入使用者物件，然後在方法裡面通過物件再去呼叫其ip出來；而是在呼叫方法前就把使用者物件的ip取出來，然後作為引數來呼叫方法。

舉例：

正面教材

public class Main {
    public static void main(String[] args) throws IOException {
        Socket socket = new Socket("localhost", 8080);
        Test test = new Test();
        test.test(socket.getLocalAddress().getHostAddress());  //在外面解析好就行了
    }

    static class Test {
        public void test(String str){   //一個字串就能搞定，就沒必要丟整個物件進來
            System.out.println("IP地址："+str);
        }
    }
}

反面教材

public class Main {
    public static void main(String[] args) throws IOException {
        Socket socket = new Socket("localhost", 8080);   //假設我們當前的程式需要進行網路通訊
        Test test = new Test();
        test.test(socket);   //現在需要執行test方法來做一些事情
    }

    static class Test {
        /**
         * 比如test方法需要得到我們當前Socket連線的本地地址
         */
        public void test(Socket socket){
            System.out.println("IP地址："+socket.getLocalAddress());
        }
    }
}