「訪問者」很多不同類型的對象

在一個應用程序中我有很多不同的對象，讓我們說：方形，圓形等......很多不同的形狀--->對不起爲簡單的例子。「訪問者」很多不同類型的對象

這一切的目的，我想創建不同類型的文檔：XML，TXT，HTML等。（如：我想掃描所有的對象（形狀）樹和產生XML文件

我認爲的自然方法是訪問者模式，我嘗試過它的工作原理:-) - 所有對象都有一個訪問方法接受IVisitor接口。 - 我有一個具體的訪客爲我想創建的每一種：（XmlVisitor,TxtVisitor等）。每個訪問者都有一種方法「訪問」每一種對象。

我的疑問是......如果我有很多對象，它看起來好像不是很好...... 從邏輯的角度來看它沒關係，我只是添加了新的形狀和方法在具體的訪問者中，就是這樣。

您認爲如何？是否可以替代？

來源

2012-11-06 Kasper

是什麼讓你覺得它可能不能很好地擴展？ – Mik378

我認爲你應該指定你看到的性能問題是關於實際的對象數量（所以實際的調用次數）還是虛擬方法函數調用添加的開銷？虛擬函數調用添加的開銷不用擔心。 – VladT

我認爲你已經正確實現了訪問者模式，因此你也實現了雙重調度機制。如果在添加新形狀和/或訪問者的情況下將「不能很好地縮放」作爲添加一堆方法的需求，那麼這只是該模式的副作用。有些人認爲這種「方法爆炸」是有害的，並選擇不同的實施方式，例如擁有「決策矩陣」對象。特別是對於這個例子，我認爲DD方法是可行的，實際上它的擴展性很好，因爲在添加新需求時添加新方法（例如添加新的訪問*方法，因爲添加了新的圖形或添加了新的圖形一個新的訪問者類需要新的文檔類型）。

HTH

來源

2012-11-06 20:04:26

我的唯一疑問是：如果大量新的不同類型的對象將被添加？但我認爲我很喜歡這個解決方案。分離關切...低耦合。如果將添加其他對象，則它們必須在具體訪問者中提供方法（例如：用於具體對象類型的XMLVisitor中的export方法）。 :-) – Kasper

在我看來，最讓你擔心的是你與許多不同類型的對象相匹配，擔心隨着越來越多的對象類型被添加，性能將受到影響。不過，我認爲您不必擔心這一點：訪問者模式的性能並未真正受到對象或訪問者的潛在數量的影響，因爲它基於虛擬表查找 - 傳遞的對象將包含鏈接（鏈接）應該被調用的方法。

因此，訪客模式儘管在間接訪問中相對昂貴，但在這方面可擴展。

來源

2012-11-06 15:58:10 Oak

我相信你有：

類層次結構（Shape在你的例子）和
操作的類層次結構（exportXML，exportToHTML等在你的例子）

你必須考慮更可能發生什麼變化 -

你應該選擇遊客模式如果類層次結構或多或少是固定的，但是你想在將來添加更多的操作。訪問者模式將允許您添加更多操作（例如JSON導出），而無需觸及現有的類層次結構。
OTOH如果操作或多或少是固定的，但可以添加更多的Shape對象，那麼您應該使用常規繼承。定義一個ShapeExport接口，該接口具有類似exportToXML,exportToHTML等方法。讓所有Shapes實現該接口。現在，您可以添加實現相同界面的新Shape，而無需觸摸現有代碼。

來源

2012-11-07 08:10:45 Sameer

「訪問者」很多不同類型的對象

回答

相關問題