設計模式相關基礎知識

設計模式的最終目的：高内聚，低耦合

設計模式的原則：

1）開放封閉原則：

類的改變是通過增加代碼進行的，而不是修改代碼

案例展示：

2）單一的職責原則：

類的職責要單一，隻對外提供一種功能，而引起類變化的原因都應該隻有一個

3）依賴倒置原則：

依賴于（抽象）接口，不要依賴具體的實作（類），也就是針對接口程式設計

圖形說明：

案例示範

#include<iostream>
using namespace std;
class HardDisk{
public:
    virtual void work() = ;
};
class Memory{
public:
    virtual void work() = ;
};
class Cpu{
public:
    virtual void work() = ;
};
class Computer{
private:
    HardDisk *m_harddisk;
    Memory *m_memory;
    Cpu *m_Cpu;
public:
    Computer(HardDisk *m_harddisk, Memory *m_memory, Cpu *m_Cpu){
        this->m_harddisk = m_harddisk;
        this->m_memory = m_memory;
        this->m_Cpu = m_Cpu;
    }
    void work(){
        m_harddisk->work();
        m_memory->work();
        m_Cpu->work();
    }
    virtual ~Computer(){
        delete m_Cpu;
        delete m_harddisk;
        delete m_memory;
    }
};
class InterCpu :public Cpu{
public:
    void work(){
        cout << "InterCpu work!" << endl;
    }
};
class KingStonHardDisk :public HardDisk{
public:
    void work(){
        cout << "KingStonHardDisk work!" << endl;
    }
};
class SanDiskMemory :public Memory{
public:
    void work(){
        cout << "SanDiskMemory work!" << endl;
    }
};
int main(void){
    Computer *computer = new Computer(new KingStonHardDisk(), new SanDiskMemory(), new InterCpu());
    computer->work();
    delete computer;
}
           

調試結果：

4）接口隔離原則：

不應該強迫客戶的程式依賴他們不需要的接口方法，一個接口隻應該提供一種對外功能，不應該把所有的操作都封裝在一個接口中去。

5）裡氏替換原則

任何抽象類出現的地方都可以用它的實作類進行替換。實際就是虛拟機制，語言級别實作面向對象的功能。

6）優先使用組合而不是繼承原則

如果使用繼承，會導緻父類的任何變換都可能影響到子類的行為。

如果使用對象組合就降低了這種依賴關系。

7）迪米特原則

一個對象應對其他對象盡可能少的了解，進而降低了各個對象之間的耦合，提高系統的可維護性。例如在一個程式中，各個子產品之間互相調用時，通常會提供一個系統的接口來實作。這樣其他子產品不需要了解其他内部子產品的内部實作細節。這樣當一個子產品内部的實作發生改變時，不會影響到其他子產品的使用（黑盒原理）

圖形說明

與依賴倒轉原則結合，某人和抽象陌生人說話