工廠模式個人案例

我有一份工作來檢查我們的項目代碼質量。 如果我在項目中發現任何障礙，必須將其報告給我的團隊負責人。 我發現了很多漏洞，我認為可以在博客上進行討論。 不是嘲笑作者，而是一起學習和改進自己。

像這段代碼一樣，這是我在我們的代碼中找到的部分。

public ContactInfoBean(final Reseller resellerInfo) {switch(resellerInfo.getType()) {case PROGRAM_CONTACT:readExecutiveInfo(resellerInfo);break;case FILE_CONTACT:readOperationalInfo(resellerInfo);break;default:break;}}

該代碼可以正常工作，并且可以很好地完成工作。 但是使用此代碼樣式會出現一些問題。 此類將隨著業務的變化而增長，與往常一樣，較大的級別是維持這種狀態的“商戶”。 最有可能具有上述目的的這一類稱為低內聚性。

更好的面向對象的方法

對于上述情況，更好的方法是使用“工廠設計模式”。 我們可以讓READER的工廠根據其類型生成每個實例。 擴展實例類型會更容易，因為我們只需要創建一個新類并在Factory類中進行一些修改即可。 呼叫者類別不會增長，并且將保持現狀。

public interface InfoReader {public void readInfo();} public class ExecutiveReader implements InfoReader {public void readInfo() {// override}} public class OperationalReader implements InfoReader {public void readInfo() {// override}}

和工廠

public class InfoReaderFactory {private static final int PROGRAM_CONTACT = 1;private static final int FILE_CONTACT = 2;public static InfoReader getInstance(Reseller resellerInfo) {InfoReader instance = null;switch (resellerInfo.getType()) {case PROGRAM_CONTACT:instance = new ExecutiveReader();break;case FILE_CONTACT:instance = new OperationalReader();break;default:throw new IllegalArgumentException('Unknown Reseller');}return instance;}}

現在，來電者

InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);reader.readInfo();

好處

使用Factory Design Pattern處理這種情況，我們可以獲得一些好處，

• 為一個任務指定一個類別意味著更容易維護，因為一個類別僅用于一個目的（模塊化/高內聚性）。 即：Operational Reader僅用于操作目的而無其他目的讀取數據。 以防萬一，在將來的一天中，我們需要另一臺Reader（例如：NonOperationalReader）。 我們只需要創建一個擴展（或實現）InfoReader類的新類，然后就可以覆蓋我們自己的readInfo（）函數。 此類Caller類不會產生任何影響。 我們只需要在Factory代碼中進行一些修改即可。

public class InfoReaderFactory {private static final int PROGRAM_CONTACT = 1;private static final int FILE_CONTACT = 2;private static final int NEW_READER = 3;public static InfoReader getInstance(ResellerInfo resellerInfo) {InfoReader instance = null;switch (resellerInfo.getType()) {case PROGRAM_CONTACT:instance = new ExecutiveReader();break;case FILE_CONTACT:instance = new OperationalReader();break;case NEW_READER:instance = new NonOperationalReader();break;default:throw new IllegalArgumentException('Unknown Reseller');}return instance;}}

• 父級組件的更高可重用性（繼承）：由于我們有父類（InfoReader），因此可以將公共函數和事物放入此InfoReader類中，以后所有派生類（ExecutiveReader和OperationalReader）都可以重用InfoReader的公共組件。 避免代碼冗余，并可以最大程度地減少編碼時間。 即使這取決于您如何執行代碼，也無法保證。

但是，它運行得很好，我們應該更改它嗎？

顯然，答案是否定的。 這只是案例研究，僅供您進一步的經驗和知識。 OOP很好，可以在任何適用的地方進行。 但是最重??要的是，如果它正在運行，請不要更改它。 如果您為了追求某種OOP方法而破壞了整個工作代碼，那將是荒謬的。 也不要天真，沒有人可以實現完美的代碼。 最重要的是我們知道什么是更好的方法。

參考： 案例研究： JCG合作伙伴 Ronald Djunaedi在Naming Exception博客上的工廠設計模式 。

翻譯自: https://www.javacodegeeks.com/2012/10/factory-design-pattern-case-study.html

工廠模式個人案例

總結

以上是生活随笔為你收集整理的工厂模式个人案例_工厂设计模式案例研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。