java - 【求喷系列】谁能普及下工厂模式的实际应用?我认为根本用不到?
怪我咯
怪我咯 2017-04-17 17:35:54
0
4
824

放假无聊在家看设计模式《head first系列》,今天看了工厂模式,分为三种:

  1. 简单工厂模式

  2. 工厂模式

  3. 抽象工厂模式

首先这3个奇葩的名字,我真是醉了,虽说干了很多年,但是真还没怎么用过,这些东西都是各类框架实现的技术,比如spring,jdbc以及log4j之类的,真实的业务场景我还真没咋用过,谁帮忙普及下。
别整网上那些没营养的例子,什么汽车啊,鸭子啊,披萨啊,真是无聊,难道都不是用数据库表存各种属性吗?非要建立出那么多类,可能是想帮助人理解吧,但实际业务场景压根没有啊,谁说出来我服谁?求喷!

我后续还有若干求喷文,希望大家踊跃的喷我~

怪我咯
怪我咯

走同样的路,发现不同的人生

全部回覆(4)
迷茫

你說對業務上沒有用到這個可以理解,還有不要認為只有類名稱為Factory的才是工廠,比如UUID對象,目前有4種版本UUID,都不是new實例化的,通過一個Factory產出各種版本的UUID,通常這樣設計的原因是為了解決大量同接口類別的創建問題,經過分組抽象後,方便進行統一管理,類似的還有encoding charset

大家讲道理

幹了那麼多年還是沒遇到那就很悲劇了,首先可以考慮跳槽換家大公司你就會遇到了。
工廠模式最簡單的就是關係型/非關係型資料庫切換,版本切換,類別庫切換。等等,你沒遇到的原因是因為不需要後期維護或根本不用考慮版本迭代,資料庫更新吧?

其他的設計模式也是各有各的作用,這東西你沒遇到感覺不重要,遇到了就會感覺這東西太好用了,十分巧妙的運用了類的封裝,繼承,多態。

再者,程式設計師進步就是研究框架源碼,語言源碼,大並發,代碼可維護性。

小葫芦

就舉個jdk的例子, Executors類別它有個newFixedThreadPool的靜態方法,介面定義如下:

public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {

可以看到,第二個參數是可以傳入一個執行緒工廠,然後Executors類別就可以根據工廠方法來建立線城池所需的執行緒。換句話說,就是你可以把你要創建線程的規則都寫在ThreadFactory中咯。比如說,讓該工廠創建的線程名字都為XXX-前綴、或者指定線程優先權等等。

這個可以說是工廠模式最常見的場景,在各個框架的應用比比皆是。學習設計模式,啃書之餘多看實際程式碼,自然才會發現模式具體作用,甚至是各種巧用的技巧。

黄舟

不論是工廠模式還是其它創建型模式,都是一個目的-為了初始化一個物件。或者說,為了建構一個資料結構模型(類別和物件本身就是一種自訂的資料結構)。

那麼,問題來了,為什麼有 new 這樣可以建立一個對象,還要使用設計模式。本質上就是一個原因,不想讓上層使用者直接使用 new 來初始化物件。 new 这样方式可以创建一个对象,还要使用设计模式。本质上就是一个原因,不想让上层使用者直接使用 new 来初始化对象。

这样的原因有很多,绝大多数原因就是对上层的使用者隔离对象创建的过程;或者是对象创建的过程复杂,使用者不容易掌握;或者是对象创建要满足某种条件,这些条件是业务的需求也好,是系统约束也好,没有必要让上层使用者掌握,增加别人开发的难度。

所以,到这时我们应该清楚了,无论是工厂模式,还是上面的战友说的开闭原则,都是为了隔离一些复杂的过程,使得这些复杂的过程不向外暴露,如果暴露了这些过程,会对使用者增加麻烦,这也就是所谓的团队合作。

面向对象封装的本身也就是为了使得对外的 API 尽可能的简化。

例如,你定义了一个 Status字段,但这个字段因为某些业务原因,需要使用整数来表示状态。那么,如果数字少了还好办,如果数字多了,上层使用者就不一定能记清楚每个数字代表的状态(比如你要做语音通信系统,那么,语音设备是有很多状态数字的)。这时,如果使用 new来创建对象,然后再对 Status

這樣的原因有很多,絕大多數原因是對上層的使用者隔離對象創建的過程;或者是對象創建的過程複雜,用戶不容易掌握 ;或者是物件創建要滿足某種條件,這些條件是業務的需求也好,是系統約束也好,沒有必要讓上層使用者掌握,增加別人開發的難度。

所以,到這時我們應該清楚了,無論是工廠模式,還是上面的戰友說的開閉原則,都是為了隔離一些複雜的過程,使得這些複雜的過程不向外暴露,如果暴露了這些過程,會對用戶增加麻煩,這也就是所謂的團隊合作。

物件導向封裝的本身也就是為了使得對外的 API 盡可能的簡化。

例如,你定義了一個 Status字段,但這個字段因為某些業務原因,需要使用整數來表示狀態。那麼,如果數字少了還好辦,如果數字多了,上層使用者就不一定能記清楚每個數字代表的狀態(例如你要做語音通訊系統,那麼,語音設備是有很多狀態數字的) 。這時,如果使用new來建立對象,然後再對Status 進行賦值,不可避免的,可能要查閱開發文檔,或者會不小心給出一個錯誤的值。這時,你不妨使用工廠模式,或者其它合適的設計模式,來進行程式碼的建造。

比如,這樣:🎜
public static class Factory
{
    public static Ixxxxxx CreateWithOpen()
    {
        var obj = new Obj();
        obj.Status = 1;
        return obj;
    }
    public static Ixxxxxx CreateWithClose()
    {
        var obj = new Obj();
        obj.Status = 2;
        return obj;
    }
}
🎜當然,使用枚舉也行,這個說穿了,就是看設計者的意願了。 🎜 🎜所以,設計模式沒有說必需在哪個場景中使用,更確切的說,應該是,當你使用了設計模式,能不能為你的團隊成員帶來方便,或者提升代碼質量,避免一些錯誤。如果是,就用,如果只是帶來了複雜,並沒有益處,那還是算了。 🎜 🎜一句話,沒有該不該用,也沒有哪些需要不需要用,用就要帶來效益,無論是對團隊還是產品品質或產品的可維護性。用不用,要以團隊配合和產品為導向,這才是對一個軟體設計師的基本要求。 🎜
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板