我剛剛發現自己正在創建一個名爲「InstructionBuilderFactoryMapFactory」的類。這是一個課程的4個「模式後綴」。這立刻讓我想起了這一點：太多「圖案後綴」 - 設計氣味？
http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern
這是一個設計的味道？我應該對這個數字施加限制嗎？
我知道一些程序員有其他的事情類似的規則（例如不低於C.間接指針的N級以上）
所有類似乎有必要給我。我有一個從字符串到工廠的（固定）映射 - 我一直都在做。這個列表變長了，我想把它移出使用構建器的類的構造函數（這是由從地圖獲得的工廠創建的......）和往常一樣，我避免了Singletons。
我把它看作是一種設計的氣味 - 如果所有這些抽象層次都拉動了足夠的重量，它會讓我覺得它。
我看不出爲什麼要命名一個類'InstructionBuilderFactoryMapFactory'？是否還有其他類型的工廠 - 不會創建InstructionBuilderFactoryMap？還是還有其他類型的需要映射的InstructionBuilder工廠？
這些是您在開始創建這些類時應該考慮的問題。可以將所有不同的工廠工廠集合成一個工廠，然後提供單獨的方法來創建工廠。也可以將這些工廠放在不同的包裝中，並給它們一個更簡潔的名稱。想想替代方法。
很多類名中的模式絕對是一種氣味，但氣味不是一個明確的指標。這是「停一會兒，重新考慮設計」的信號。很多時候，你坐下來認爲一個更清晰的解決方案變得明顯。有時由於手頭的限制（技術/時間/人力/等等），意味着現在應該忽略氣味。
至於具體的例子，我不認爲花生畫廊的建議是沒有更多上下文的好主意。
一個好的提示是：你的類公共API（包括它的名字）應該揭示意圖，而不是實現。我（作爲客戶）不關心你是否實現了構建器模式或工廠模式。
不僅類名看起來不好，它也沒有說明它的作用。它的名字是基於其實施和內部結構。
我很少在一個類中使用模式名，除了（有時）工廠。
編輯：
發現一個有趣的article關於編碼恐怖命名，請檢查出來！
InstructionBuilderFactoryMapFactory的名稱如下 - 創建InstructionBuilderFactoryMap。客戶端有一個合適的名稱（簡稱「Parser」），用於它*做什麼。爲什麼它*想要*一個IBFM沒有透露，但它確實（在這種情況下是IBFMF）必須創建它。 – finnw 2008-09-26 00:31:11
我一直在想同樣的事情。就我而言，大量的工廠是由「可測試性構建」引起的。例如，我有這樣的構造函數：
ParserBuilderFactoryImpl(ParserFactory psF) {
...
}
這裏我有一個解析器 - 我需要的最終類。 解析器是通過在構建器上調用方法來構建的。 構建器（需要構建每個解析器的新構建器）從構建器工廠獲取。
現在，什麼h..l是ParserFactory？啊，我很高興你問了！爲了測試解析器生成器實現，我需要調用它的方法，然後查看創建了哪種解析器。要做到這一點，只要不破壞構建器創建的特定解析器類的封裝，就是在解析器創建之前放置一個攔截點，以查看構造器中的內容。因此ParserFactory。這只是我在單元測試中觀察傳遞給解析器構造函數的一種方式。
我不太清楚如何解決這個問題，但我有一種感覺，我們應該更好地傳遞類而不是工廠，如果Java可以有適當的類方法而不是靜態成員，那麼Java會更好。
看，這就是爲什麼我討厭Java。您（很有可能）在C++中看不到具有該名稱的類。 – davr 2008-09-26 00:18:37
你使用的是IOC容器嗎？ – 2009-02-05 00:34:56