不，這不是上帝說的。

這也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky（可以用你最喜歡的技術(shù)專家的替換這些名字）說的。

我們正在審查一些代碼，并開始討論為什么我們走捷徑，不遵循常識原則。雖然每個人在對待關(guān)于類應(yīng)該如何基于功能上下文來構(gòu)建的問題上都有自己的智慧，但仍然有一些基本原則值得我們在設(shè)計類的時候牢牢記住。

I.遵循單一職責(zé)原則

每個類都應(yīng)該有一個并且只有一個引起它變化的原因。這不僅適用于類，方法也是如此。不知道你有沒有見到過那些長篇大論的冗余的類和方法，當(dāng)將它們寫到紙上的時候，簡直就是懶婆娘的裹腳布——又臭又長？好吧，我們要提出的觀點(diǎn)是不要這樣做。

該原則的要點(diǎn)就是每個類或方法都有一個存在的理由。如果類被命名為Loan，那么它就不應(yīng)該處理銀行帳戶的相關(guān)細(xì)節(jié)。如果方法被命名為GetLoanDetails，那么它應(yīng)該負(fù)責(zé)獲取貸款的詳細(xì)信息！

II.遵循開放封閉原則

這一條使你能夠思考你的系統(tǒng)將如何適應(yīng)未來的變化。它指出，系統(tǒng)應(yīng)該允許添加新的功能，但對現(xiàn)有代碼的更改要做到最少。因此，設(shè)計對于擴(kuò)展應(yīng)該是開放的，但對于修改應(yīng)該是封閉的。在我們的例子中，開發(fā)人員做了這樣的事情：

public class PersonalLoan
{
    public void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class AutoLoan
{
    public void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class LoanProcessor
{
    public void ProcessEarlyTermination(object loan)
    {
        if ( loan is PersonalLoan )
        {
            //Personal Loan processing
        }
        else if (loan is AutoLoan)
        {
            //Auto Loan Processing
        }
    }
}

LoanProcessor的問題是，當(dāng)有一種新類型的Loan，例如HomeLoan出現(xiàn)的時候，它將不得不改變。結(jié)構(gòu)最好是這樣：

public abstract class Loan
{
    public abstract void Terminate();
}
public class PersonalLoan: Loan
{
    public override void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class AutoLoan: Loan
{
    public override void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class LoanProcessor
{
    public void ProcessEarlyTermination(Loan loan)
    {
        loan.Terminate();
    }
}

這樣的話，如果添加了新類型的Loan，那么LoanProcessor也不會受影響。

III.嘗試使用組合優(yōu)于繼承

如果不能正確地遵循這一條原則，那么可能會導(dǎo)致脆弱的類層次。這個原則真的很簡單，只需要問一個問題——如果我要看子類，那么我能不能說“Child是Parent的一種類型？”或者，它更像“Child某種程度上是Parent的一種類型？“

始終對第一個問題使用繼承，因為它將允許使用Child無論P(yáng)arent在哪里。這也將允許你能夠?qū)崿F(xiàn)另一個稱為Liskov替代原則的設(shè)計原則。并且在你想部分使用一個類的功能的時候使用組合。

IV.封裝數(shù)據(jù)和行為

大多數(shù)開發(fā)人員只做數(shù)據(jù)封裝，忘記封裝基于上下文而變化的代碼。不但隱藏類的私有數(shù)據(jù)很重要，而且創(chuàng)建被良好封裝的作用于私有數(shù)據(jù)的方法也很重要。

V.類遵循松散耦合原則

這與封裝正確的行為是相輔相成的。如果行為被很好地封裝在類中，那么就只能創(chuàng)建松散耦合的類。我們可以通過依賴于抽象而不是實現(xiàn)來做到松散耦合。

VI.使類高度內(nèi)聚

我們不應(yīng)該在不同的類之間散開數(shù)據(jù)和行為。應(yīng)該努力使類不泄露/打破實現(xiàn)到其他類的細(xì)節(jié)。這意味著不允許類有代碼，因為這樣超出了它存在的目的。當(dāng)然，有一些設(shè)計范例，如CQRS，會希望你在不同的類中隔離某些類型的行為，但它們只用于分布式系統(tǒng)。

VII.編碼接口而不是實現(xiàn)

這促進(jìn)了松散耦合原則，并使得我們能夠改變底層實現(xiàn)或引入新的實現(xiàn)，而不影響使用它們的類。

VIII.保持DRY（Don’t Repeat Yourself）

也是一個聲明不要在兩個不同的地方重復(fù)相同代碼的設(shè)計原則。也就是說，特定功能或算法應(yīng)當(dāng)，僅，在一個地方實現(xiàn)。如果重復(fù)實現(xiàn)的話，則會導(dǎo)致維護(hù)問題。與此相反的是WET原則——Write Everything Twice。

IX.最少知識原則，也叫做迪米特法則。

這個原則聲明對象不應(yīng)該知道它協(xié)作對象的內(nèi)部細(xì)節(jié)。它被著名地稱為——與朋友交流，不要和朋友的朋友交流。類應(yīng)該只能調(diào)用它正在協(xié)作的類的公共數(shù)據(jù)成員。不應(yīng)該被允許訪問由那些數(shù)據(jù)成員組成的類的行為或數(shù)據(jù)。如果不能正確遵守，則會導(dǎo)致緊密耦合，從而創(chuàng)建出更難改變的系統(tǒng)。

X.遵循好萊塢原則：Don’t Call Us, We’ll Call You

這能夠打破條件流邏輯的模型，并允許基于事件執(zhí)行代碼。這要么通過事件回調(diào)，要么通過注入接口的實現(xiàn)來完成。依賴注入，控制反轉(zhuǎn)或觀察者設(shè)計模式都是這個原則的好例子。這個原則促進(jìn)了類之間的松散耦合，并使得實現(xiàn)非�？删S護(hù)。

英文原文：10 Commandments of Object-Oriented Design

標(biāo)簽： 代碼

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。