OOP：應用程序體系結構問題

那些我讀過的「壞應用程序體系結構」這樣一個例子時間：

有一個「渲染應用」（瀏覽器，據我所知），所以有人告訴我，在TagA，TagUL，TagDIV類中使用「render（）」方法是非常糟糕的做法，因爲你會有很多「渲染代碼」四處抹黑。所以（在這個例子中），他們建議使用RenderA，RenderUL，RenderDIV類來實現渲染。標籤對象會包裝那些渲染器。

我不明白爲什麼這是一個不好的做法。在這種情況下，我們會在Render- *對象周圍塗抹很多渲染代碼。最後，爲什麼不讓Redner-singleton有很多重寫方法？聽起來，至少，更便宜。

看什麼瞭解它更好？

來源

2012-05-29 Ben Usman

所有這些不同對象的渲染是否相同？如果是這樣，那麼它只應該實施一次，最有可能在基礎類。這是一個比Singleton更好的解決方案，它提供了一個完全不同的目的：主要是實現一個應該只存在一次的資源（注意它的資源，而不是方法）。

如果render（）的每個實現都不同（這很可能是這種情況），那麼它們在單獨的對象中實現沒有什麼問題，這稱爲polymorphism。然而，應該做的是，有一個類層次結構，其中render（）方法在基類中定義（很可能是抽象的）並在派生類中實現。這有效地形式化了接口，意味着從所述基類繼承的任何類都將具有可用的render（）方法，並且必須實現它。

如果您有部分渲染代碼是通用的，並且部分是特定於派生類的，而不是必須在所有派生類實現中複製公共部分，則可以使用Template Method模式，基類方法執行公共部分，並協調調用派生類實現。這是在C++

class TagBase { 
public: 
    void render() { 
     // do some common stuff here 
     doRender(); 
     // do some more common stuff here 
    } 

    virtual void doRender() = 0; 
    .... 
}; 

class TagA : public TagBase { 
public: 
    virtual void doRender() { 
     // do your specific stuff here 
    } 
};

這裏有一些好書僞代碼示例：

來源

2012-05-29 10:11:26 Brady

我的意思是某種「RenderManager-Singleton」，只是一個假設。是的，使用基類中的抽象render（）方法對我來說似乎也是邏輯。但有些人覺得它「抹黑」。 –

那麼，關於塗抹，考慮替代方法：一個大的凌亂的函數，有很多if/else塊用於不同的情況。我會在答案中添加更多細節，以顯示如何避免模糊。 – Brady

@Minner，我也加了一些書 – Brady

我不能明白爲什麼這是一個不好的實踐即

如果Tag不是自己渲染的責任，請參閱Single Responsibility Principle。例如，如果Tag類已經包含HTML解析行爲，並且向其添加了渲染，則它將具有2個職責，其中有2個原因需要更改並且可能會中斷。由於它們的搭配，解析將緊密結合呈現，帶來了一系列問題：

您不能更改或變體獨立於其他增加的職責之一 - 例如加入移動除了桌面瀏覽器呈現之外，瀏覽器呈現將需要編寫另一個類來重複解析行爲。規模更小，職責更專注，意味着更多的活動部件和增加的模塊化。
類別嵌入的責任越多，更改錯誤和副作用可能會在您進行更改時意外出現。在很多情況下，很難判斷哪個責任導致了錯誤。
即使您只對其中一個職責進行了更改，您也必須重新構建，重新測試並重新部署課程中包含的所有職責。
當其他人干擾它時，調試其中一個責任也更困難。

來源

2012-05-29 12:43:56 guillaume31

OOP：應用程序體系結構問題

回答

相關問題