【抽象那些事】 指令式抽象

指令式抽象

這種壞味是由操作轉換為類引起的，表現為類中隻定義了一個方法，有時候類名和方法名相同。這種壞味還常常表現為方法操作的資料位于另一個類中。

為什麼不能指令式抽象？

面向對象的基本原則是，識别真實世界中的事物，并使用抽象來表示它們。在解決方案域中，必須将問題域的對象表示出來，為此可采用映射域實體這一實作手法，抽象的每個類都必須封裝資料和相關的方法。隻包含一個操作的類根本不是抽象，其操作的資料位于其它地方時尤其如此。這樣很多操作相同資料的方法位于不同的類中，減低了類的内聚性，違反了封裝和子產品化原則。

指令式抽象潛在的原因

過程式思維

資料和操作這些資料的方法被封裝在不同類中，典型的過程式思維。

示例分析

來看報表生成功能，它使用了CreateReport、CopyReport、DisplayReport等類。其中每個類隻包含一個方法。與報表相關的資料項，如報表名稱等都放在了Report類。很顯然程式中存在“指令式抽象”，這種壞味不僅增加了類的數量（至少4個類，理想情況下隻需要1個類），而且内聚的方法進行了分離，增加了開發和維護的複雜性。該設計采取的是“功能分解”，而非“面向對象分解”。

public class Report
{
    public string ReportName { get; set; }
}

public class CreateReport
{
    public void Create()
    {
        //Create
    }
}

public class DisplayReport
{
    public void Display()
    {
        //Display
    }
}

public class CopyReport
{
    public void Copy()
    {
        //Copy
    }
}           

複制

重構：我們将所有存在“指令式抽象”壞味的類中的方法都移到Report類中，那麼Report類就變成了一個恰當的抽象，同時消除了“指令式抽象”壞味。

重構後的實作：

public class Report
{
    public string ReportName { get; set; }

    public void Create()
    {
        //Create
    }
    public void Display()
    {
        //Display
    }
    public void Copy()
    {
        //Copy
    }
}           

複制

現實考慮

具體化

具體化指的是将不是對象的東西提升為對象。将行為具體化後，便可對其進行存儲、傳遞和轉換。具體化可提高系統的靈活性，但是代價是增加了系統的複雜度。

很多設計模式都使用了具體化：狀态模式、指令模式、政策模式。

為了提高可重用性、靈活性和可擴充性而有意識地将原本不是對象的東西提升為對象，這不能算是壞味。

參考：《軟體設計重構》

                                                       -----END-----

          喜歡本文的朋友們，歡迎掃一掃下圖關注公衆号撸碼那些事，收看更多精彩内容