工厂模式个人案例_工厂设计模式案例研究
工廠模式個(gè)人案例
我有一份工作來檢查我們的項(xiàng)目代碼質(zhì)量。 如果我在項(xiàng)目中發(fā)現(xiàn)任何障礙，必須將其報(bào)告給我的團(tuán)隊(duì)負(fù)責(zé)人。 我發(fā)現(xiàn)了很多漏洞，我認(rèn)為可以在博客上進(jìn)行討論。 不是嘲笑作者，而是一起學(xué)習(xí)和改進(jìn)自己。像這段代碼一樣，這是我在我們的代碼中找到的部分。
public ContactInfoBean(final Reseller resellerInfo) {switch(resellerInfo.getType()) {case PROGRAM_CONTACT:readExecutiveInfo(resellerInfo);break;case FILE_CONTACT:readOperationalInfo(resellerInfo);break;default:break;}}該代碼可以正常工作，并且可以很好地完成工作。 但是使用此代碼樣式會(huì)出現(xiàn)一些問題。 此類將隨著業(yè)務(wù)的變化而增長(zhǎng)，與往常一樣，較大的級(jí)別是維持這種狀態(tài)的“商戶”。 最有可能具有上述目的的這一類稱為低內(nèi)聚性。
更好的面向?qū)ο蟮姆椒?/strong>
對(duì)于上述情況，更好的方法是使用“工廠設(shè)計(jì)模式”。 我們可以讓READER的工廠根據(jù)其類型生成每個(gè)實(shí)例。 擴(kuò)展實(shí)例類型會(huì)更容易，因?yàn)槲覀冎恍枰獎(jiǎng)?chuàng)建一個(gè)新類并在Factory類中進(jìn)行一些修改即可。 呼叫者類別不會(huì)增長(zhǎng)，并且將保持現(xiàn)狀。
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;}}現(xiàn)在，來電者
InfoReader reader = InfoReaderFactory.getInstance(resellerInfo);reader.readInfo();好處
使用Factory Design Pattern處理這種情況，我們可以獲得一些好處，
- 為一個(gè)任務(wù)指定一個(gè)類別意味著更容易維護(hù)，因?yàn)橐粋€(gè)類別僅用于一個(gè)目的（模塊化/高內(nèi)聚性）。 即：Operational Reader僅用于操作目的而無其他目的讀取數(shù)據(jù)。 以防萬一，在將來的一天中，我們需要另一臺(tái)Reader（例如：NonOperationalReader）。 我們只需要?jiǎng)?chuàng)建一個(gè)擴(kuò)展（或?qū)崿F(xiàn)）InfoReader類的新類，然后就可以覆蓋我們自己的readInfo（）函數(shù)。 此類Caller類不會(huì)產(chǎn)生任何影響。 我們只需要在Factory代碼中進(jìn)行一些修改即可。
- 父級(jí)組件的更高可重用性（繼承）：由于我們有父類（InfoReader），因此可以將公共函數(shù)和事物放入此InfoReader類中，以后所有派生類（ExecutiveReader和OperationalReader）都可以重用InfoReader的公共組件。 避免代碼冗余，并可以最大程度地減少編碼時(shí)間。 即使這取決于您如何執(zhí)行代碼，也無法保證。
但是，它運(yùn)行得很好，我們應(yīng)該更改它嗎？
顯然，答案是否定的。 這只是案例研究，僅供您進(jìn)一步的經(jīng)驗(yàn)和知識(shí)。 OOP很好，可以在任何適用的地方進(jìn)行。 但是最重??要的是，如果它正在運(yùn)行，請(qǐng)不要更改它。 如果您為了追求某種OOP方法而破壞了整個(gè)工作代碼，那將是荒謬的。 也不要天真，沒有人可以實(shí)現(xiàn)完美的代碼。 最重要的是我們知道什么是更好的方法。
參考： 案例研究： JCG合作伙伴 Ronald Djunaedi在Naming Exception博客上的工廠設(shè)計(jì)模式 。
翻譯自: https://www.javacodegeeks.com/2012/10/factory-design-pattern-case-study.html
工廠模式個(gè)人案例
總結(jié)
以上是生活随笔為你收集整理的工厂模式个人案例_工厂设计模式案例研究的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Eclipse IDE中的Java 9
- 下一篇： Apache Spark软件包，从XML