使用外觀設計模式|缺點/解決方案/建議

Facade Object中的每種方法都是在幾個接口中公開的幾種其他方法的組合。在這段時間內，隨着我們將瞭解通過組合複雜系統中可用的不同接口和其方法可以實現的不同操作，該對象也將增長。使用外觀設計模式|缺點/解決方案/建議

我的問題很簡單：

1）這是一個更好的選擇與門面繼續下去還是我們有一些可用的其他選擇？因爲隨着我們增加適應Facade對象中每個新操作的方法數量，它也變得複雜。 我可以想到的一個可能的解決方案是創建一個門面

2）另外，當我們說它變得複雜時，是否有由門面暴露的限制方法？ Update：我的分析說，如果它很難理解和重新考慮你的設計，停止向門面添加更多的方法; is that it？

來源

2013-10-14 Rupesh

由於問題是相當開放的，我推薦Head First Design Patterns ch。 7，那裏解釋了很多最佳實踐。而2） - 限制是它開始讓你和你的程序員感到困惑。 – LastFreeNickname

@LastFreeNickname：哪一部分你不明白？請讓我知道我也會嘗試添加。 – Rupesh

由於您的問題非常抽象，因此很難以確保您所寫內容的具體內容來回答問題。

據我所知，你問的問題是真的，如果你有

interface A { public void a(); } 
interface B { public void b(); } 

class ABFacade { 
    private final A a = ... 
    private final B b = ... 
    public void ab() { a.a(); b.b(); } 
}

則是有用與否？

答案是要依賴於

問題域 - 如何定義的呢？
如何命名事物 - 人們會理解它嗎？
代碼重用 - 是否有不止一件事情需要調用facade方法？

我不認爲有一個正確的答案 - 至少沒有具體的例子。這也取決於使用這種模式的目的是什麼 - 更好的代碼重用？更少的重複代碼集可以完成一些複雜的事情？創建阻塞點所有X必須通過的代碼？對其他開發人員的清晰度？這個問題的答案會深刻地影響你的代碼的外觀。

我可以推薦一些一般的東西，這可能有助於產生一些有用的東西：

如果一個門面方法將只在一個地方使用，但可能不應該是在門面 - 如果它的代碼只有一個客戶端，這可能是更有意義的做內聯的所有步驟
可以對立面上的某些操作給出明確的命名？結果會比寫出正面所做的一切更直觀嗎？如果是這樣，那麼這可能應該在門面

最後，它只是一個模式。如果它允許您編寫更小，更好或更可靠的軟件，請使用它;如果沒有，請不要打擾。

來源

2013-10-14 07:01:27

有用的答案，但正如您在答案中突出顯示的那樣，* ab *是您創建的操作，只是爲了執行一項操作，然後可以有多個這樣的組合。我的問題是圍繞着這些線，當你確定新的操作，並考慮添加新的方法，你的立面OBJ，使它更重。我認爲Facade不會比幫助。 – Rupesh

@Tim Boudreau'如果一個門面方法只能在一個地方使用，那麼它可能不配置在門面中。「不是在DI方面，它對聚合服務非常有用：http：// blog。 ploeh.dk/2010/02/02/RefactoringtoAggregateServices/。並且「內嵌所有步驟」違反了SRP並違反了TDD，因此降低了可維護性。 – Fendy

我也不同意'如果一個門面方法只能用在一個地方...'。這就像說如果要從一個地方調用方法就不要製作方法。 – weston

使用外觀設計模式|缺點/解決方案/建議

回答

相關問題