設計模式——面向對象設計原則

在應用程式開發中，一般要求儘量兩做到可維護性和可復用性。應用程式的復用可以提高應用程式的開發效率和質量，節約開發成本，恰當的復用還可以改善系統的可維護性。而在面向對象的設計裡面，可維護性復用都是以面向對象設計原則為基礎的，這些設計原則首先都是復用的原則。遵循這些設計原則可以有效地提高系統的復用性，同... ...

面向對象設計原則

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

單一職責原則

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

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

人可以乾的事情有很多：敲代碼、唱歌、跳舞、打籃球....以人設置成一個類，裡面的方法就太多太雜了。所以可以有多個類：程式員（敲代碼）、音樂人（唱歌）、愛豆（跳舞）、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());
        }
    }
}