SOLID 設計原則 - 單一職掌原則(SRP)

良好的物件導向設計,有賴於遵循相關的設計原則,想像大規模應用,其中包含大量的類別與複雜的衍生關係,任何系統的擴充或是修正作業,都會導致更新部署問題,良好的設計可以有效的降低系統維護的負擔。

SOLID 包含「單一職責原則(SRP)」、「開放-封閉原則(OCP)」、「Liskov 替換原則(LSP)」、「介面隔離原則(ISP)」以及「相依性反轉原則(DIP)」,這一篇先就「單一職責原則(SRP)」進行討論。

單一職掌原則(SRP)

任何物件都應該專注單一的任務職掌,而且只有單一的理由可以導致物件的異動,「單一職責原則(SRP)」相較其它是比較容易理解的設計原則,以下利用一個範例進行說明。

考慮以下的類別:

public class UnitConversion
{
    public double OZConversion(double o)
    {
        double c = 0.033814;
        double ml = o / c;
        return ml;
    }
    public double TemperatureConversion(double c)
    {
        double f = c * 9 / 5 + 32;
        return f;
    }
}

其中配置了兩組方法,OZConversion支援盎司與毫升單位轉換運算,而TemperatureConversion 攝氏與華氏溫度轉換,這兩組方法提供不同種類的單位轉換,如果要調整其中任何一種轉換邏輯或是進一步擴充其它單位轉換功能,都必須修改 UnitConversion 類別,比較好的作法是以獨立的類別提供所需的功能,以下將功能移至獨立的類別:

public class OZConversion
{
    public double Conversions(double o)
    {
        double c = 0.033814;
        double ml = o / c;
        return ml;
    }
}
public class TemperatureConversion
{
    public double Conversions(double c)
    {
        double f = c * 9 / 5 + 32;
        return f;
    }
}

現在 OZConversion 的 Conversions 方法專注在盎司毫升的單位轉換功能,而 TemperatureConversion 中的 Conversions 方法,則專注在溫度的轉換功能,如此一來遵循了 SRP 設計,後續不需要為了修改其中任何方法,影響其它類別。

SRP可以有效的避免複雜的功能設計,藉此提高程式的可讀性,讓系統的維護更為容易,但如此一來亦衍生了其它的問題,我們可以藉由進一步遵循「開放-封閉原則(OCP)」設計來避免,這一部份下一篇進行討論。



沒有留言: