模式到今天已經(jīng)20年歷史了, 尤其是GoF模式, 更廣泛被大家熟知, 這些模式就像武俠小說里的招式, 什么時(shí)候該使用什么招式, 師傅們只能泛泛而談, 正確的判斷必須由我自己的做出. 以后會(huì)介紹些自己的淺薄經(jīng)驗(yàn), 并和大家討論, 只是不知道如何寫起; 無論你是存在問題, 還是已經(jīng)有了自己的答案, 都可以給我留言; 對(duì)于前者我不見得會(huì)馬上回復(fù), 但是對(duì)我如何去寫有很大啟發(fā).
在這里先整理一些有疑問的使用方式, 作為未來的素材.
職責(zé)鏈?zhǔn)褂们榫耙? 原帖
在表達(dá)我的想法之前, 我們先優(yōu)化一下作者原來的代碼中如下部分, 雖然這些優(yōu)化中有一些對(duì)于真正的職責(zé)鏈模式是錯(cuò)誤的, 而在這情況下使用鏈表是存在很大疑問的, 但是我們?nèi)绻痪心嘤诼氊?zé)鏈稱號(hào), 也不考慮使用鏈表的合理性, 則這些優(yōu)化可以當(dāng)作一次重構(gòu)的展示:
對(duì)象一:
if (變量 == "信息一") 某操作 else if (存在下一個(gè)對(duì)象) 下一對(duì)象.執(zhí)行() else 默認(rèn)操作
對(duì)象二:
if (變量 == "信息二") 某操作 else if (存在下一個(gè)對(duì)象) 下一對(duì)象.執(zhí)行() else 默認(rèn)操作
...
...
這是什么? 這就是重復(fù), 這種重復(fù)如果混進(jìn)代碼里往往沒有那么明顯; 先把最明顯的部分搞掉吧:
public class BasicHttpBindingConstraint:BindingConstraint
{
public override bool Constraint(ServiceEndpoint endpoint)
{
if (endpoint.Binding.Name == "BasicHttpBinding")
{
//原操作
}
return base.Constraint(endpoint);
}
}
判斷是否有下一個(gè)等等寫入基類, 還是原來那些代碼. 這樣重構(gòu)的好處除了消除了代碼重復(fù), 原文中兩個(gè)protected的字段, 也不用再向?qū)崿F(xiàn)類暴露, 做到了更好的信息隱藏. 但是真的沒有重復(fù)了嗎? 看看這句: if (endpoint.Binding.Name == "BasicHttpBinding"), 其中變化的只有引號(hào)內(nèi)部的部分, 其余的還是重復(fù). 同時(shí), 每一個(gè)實(shí)現(xiàn)類, 雖然不用寫else了但是base.Constraint(endpoint)卻得Copy&Paste一遍.
接下來我們這么干一下基類:
public abstract class BindingConstraint//:IEndpointConstraint
{
#region protected fields
//只要是field, 最好連protected也不要.
#endregion
private BindingConstraint m_bindingConstraint; //與原來相比, private做到了更好的信息隱藏
private bool m_hasNextConstraint = false;
#region public methods
public void AddConstraint(BindingConstraint constraint)
{
m_bindingConstraint = constraint;
m_hasNextConstraint = true;
}
public bool Constraint(ServiceEndpoint endpoint) //注意, 不再abstract了
{
if (BindingConstraintName == endpoint.Binding.Name)
{
return DoConstraint(endpoint);//注意, 這么優(yōu)化是不對(duì)的, 見后面關(guān)于職責(zé)鏈的討論
}
else
{
if (m_hasNextConstraint)
{
return m_bindingConstraint.Constraint(endpoint);
}
else
{
return false;
}
}
}
#endregion
#region public abstract methods
//新增了兩個(gè)
protected abstract bool DoConstraint(ServiceEndpoint endpoint);
protected abstract String BindingConstraintName
{
get;
}
#endregion
}
根據(jù)傳說中的單一職責(zé), 作為實(shí)現(xiàn)的子類, 無需再負(fù)責(zé)鏈表的相關(guān)工作, 只要管自己干嘛, 并提供自己負(fù)責(zé)事情的代號(hào), 就可以了. 但是我要說明的是, GoF的代碼例子, 是我和當(dāng)前例子的作者的那個(gè)中間值: 第一次優(yōu)化后那個(gè)結(jié)果; 為什么呢?
第一次優(yōu)化后, base.Constraint(endpoint)這個(gè), 還可以不執(zhí)行, 這樣我們就有了一個(gè)機(jī)會(huì), 定義默認(rèn)操作, 甚至將職責(zé)鏈原本的鏈條改變, 引導(dǎo)到另外一個(gè)職責(zé)鏈上去. 請(qǐng)大家注意這個(gè)事實(shí): 使用base.Constraint(endpoint)的方法, 增加了重復(fù), 但換到了靈活性; 也就是說, 只要是損失的, 必須換來其它的東西, 否則回家咱老婆也不干啊不是.
只是針對(duì)這個(gè)例子, 把去優(yōu)化它兩次沒啥問題, 不過仍然可以看作吃飽了撐的沒事干, 唯一的作用就是順便就問這么一個(gè)事情:
信息隱藏完美, 沒有重復(fù), 使用優(yōu)雅, 對(duì)擴(kuò)展開放, 一切符合教科書上各種原則的代碼. 就一定是正確的代碼嗎?
該文作者使用鏈表作設(shè)計(jì), 無可厚非, 畢竟, 他達(dá)到了他想要的目的; 但是其實(shí)這種用法, 存在著一個(gè)的問題: 鏈表上每一個(gè)對(duì)象, 都要保存著上一個(gè)對(duì)象的引用, 從接到請(qǐng)求, 到有一個(gè)對(duì)象響應(yīng), 中間有多少個(gè)對(duì)象, 就有多少個(gè)廢開銷. 有開銷沒有問題, 問題是開銷換來的是什么? 該文作者總結(jié)到:
引用(錯(cuò)誤!見后)使用職責(zé)鏈模式必須恰到好處，否則會(huì)成為模式濫用的反面教材。根據(jù)我對(duì)職責(zé)鏈模式的理解，可以認(rèn)定只要同時(shí)符合下列三個(gè)條件，就可以引入職責(zé)鏈模式：
1、當(dāng)一個(gè)方法的傳入?yún)?shù)將成為分支語句的判斷條件時(shí)；
2、當(dāng)每一個(gè)分支的職責(zé)相對(duì)獨(dú)立，且邏輯較為復(fù)雜時(shí)；
3、當(dāng)分支條件存在擴(kuò)展的可能時(shí)。
我的看法是, 基本上打到靶子外去了. 那些可能產(chǎn)生的開銷, 其實(shí)是白白犧牲了還被扣了個(gè)"廢"的帽子; 勤奮工作的CPU, 被我一個(gè)初學(xué)者硬生生的釘上了"貪污和浪費(fèi), 是極大的犯罪"的歷史的恥辱柱. 我們這次付出, 不像上面GoF的老大們選擇的不優(yōu)化, 反而像談戀愛, 大把的白花花的銀子花出去, 最后只等到一張好人卡~
比如用Strategy模式實(shí)現(xiàn), 照樣可以得到這些好處. 比如該文作者的例子:
1. 創(chuàng)建一個(gè)類作為執(zhí)行者, 執(zhí)行者中持有一個(gè)保寸字符串和IBindingConstraint的字典(比如Dictionary, HashTable);
2. 這個(gè)字典的初始化, 既可以用原來Add的方式, 也可以通過一個(gè)配置文件初始化;
3. 實(shí)現(xiàn)一個(gè)Execute, 根據(jù)endpoint.Binding.Name從字典取出IBindingConstraint, 并執(zhí)行Constraint;
4. 使用時(shí)調(diào)用: 推薦者.Execute(endpoint).
很顯然, 這樣的做法, 不但有更小的開銷, 也有更少的代碼, 同時(shí)擁有更合理的結(jié)構(gòu). 在這里我要隆重的提醒大家注意使用字典, 這種方式雖然不入GoF 23種模式大雅之堂, 卻是n多大牛/大嘴推薦的萬靈丹. 對(duì)字典的使用也有一個(gè)廣泛學(xué)名, 叫做"表模式"(還是什么來著? 記性不好...). 當(dāng)然就針對(duì)當(dāng)前的討論所針對(duì)的問題來說, 我們也可以把它理解為策略模式的一個(gè)應(yīng)用.
為什么說這種方式更合理呢? 讓我們來看一下原文作者所說的三條, 其模型到底是什么樣的:
信息1 -> 過程或?qū)ο笠?BR>信息2 -> 過程或?qū)ο蠖?BR>....
SELECT 對(duì)象 FROM 某處 WHERE 信息 = @變量, 查表, 赤裸裸的查表! 職責(zé)鏈呢? 作為一個(gè)設(shè)計(jì)模式, 僅僅是針對(duì)查表然后執(zhí)行算法, 那策略模式早就對(duì)這個(gè)搶飯碗的提反對(duì)意見了. 事實(shí)上職責(zé)鏈到底是干嘛地的呢? 搞清楚這個(gè)問題, 就可以判斷真正的職責(zé)鏈在這里是不是合適, 或者原文作者使用鏈表的方式, 是否是職責(zé)鏈所覆蓋的范疇了.
DP955.1 CHAIN OF RESPONSIBILITY
1. 意圖
使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求......
2. 動(dòng)機(jī)
考慮一個(gè)圖形界面中上下文有關(guān)的幫助機(jī)制.....如果對(duì)于那一部分界面沒有特定的幫助信息, 那么...顯示一個(gè)關(guān)于當(dāng)前上下文的較一般的幫助信息, 比如說.....
因此很自然地, 應(yīng)根據(jù)普遍性即從最特殊的到最普通的順序來組織..
3. 適用性
有多個(gè)對(duì)象可以處理一個(gè)請(qǐng)求, 哪個(gè)對(duì)象處理一個(gè)請(qǐng)求運(yùn)行時(shí)刻自動(dòng)確定.
...
...
找啊找啊找朋友, 找到一個(gè)女朋友~ 沒錯(cuò), 職責(zé)鏈說的就是這個(gè)事: 你認(rèn)識(shí)一個(gè)特別出色的女人, 你跟她說, 做我馬子吧, 如果她同意了, 自然好; 如果她說, 你就像我哥哥, 于是你說了, 既然我是你哥哥, 你得幫哥哥介紹一個(gè)吧? 她為了盡快擺脫你, 把一個(gè)比她差點(diǎn)的朋友介紹給了你, 然后你說, 做我馬子吧... 如此下去, 直到有一個(gè)人接受你為止.
有一個(gè)問題我們要想到: 假設(shè)那個(gè)特別出色的女人是A, 她那天正好想到的朋友是B, 你就去給B花錢了; 如果想到的是C, 那你就是給C花錢; 同時(shí), B如果不同意, 也許會(huì)給你C的電話, 也許會(huì)給你D或者E的電話. 而BCDE都有可能接受你. 也就是說, 誰把你接收了是不一定的, 但總有一個(gè)能接收你, 當(dāng)然這里假設(shè)你是個(gè)女人就行, 換個(gè)說法, 你是無要求的, 響應(yīng)者是不固定的. 將Gof的例子形象化, 想像所有的東西都是卡片, 疊在一起 如下:
--
------
--------------
--------------------
從正上方看, 是一個(gè)窗口平面, 最頂層的那個(gè)區(qū)域是某種Widget1, 下面一種是 Widget2, 再下面一種是Widget3, 最底下是4, 記住, 全都是不同的class, 繼承自一個(gè)Handler. 當(dāng)我們用小問號(hào)點(diǎn)擊Widget1所在區(qū)域的時(shí)候, 如果Widget1含有幫助信息, 就顯示W(wǎng)idget1的, 如果沒有, 就顯示W(wǎng)idget2的以此類推. 當(dāng)然, 真實(shí)的例子不會(huì)這么擺, 只會(huì)比這個(gè)更復(fù)雜, 從最底層的對(duì)象開始, 往上基本是一個(gè)樹狀的樣子. 我們可以認(rèn)為上面的圖, 是這棵樹某一個(gè)分支, 正好就這么簡單.
我們換一個(gè)放法: Widget1下面是Widget7, Widget3, Widget9(按順序), 也就是說, 隊(duì)伍根本不同了; 尋找的過程仍然相似, 只是最終顯示的幫助信息有可能不一樣. 為什么呢? 我們考慮一個(gè)控件: Label. Label本身一般沒有幫助, 我們把它放入Widget2里, 它如果被點(diǎn)擊了, 其效果和點(diǎn)擊Widget2應(yīng)該是一樣的; 換成Widget7如果Widget7有幫助, 就應(yīng)該顯示W(wǎng)idget7的幫助. 但如果正好Widget7也沒有幫助呢? 就顯示W(wǎng)idget3的唄, 因?yàn)長abel既然是Widget7的一部分, 顯然也是Widget3的一部分; Widget7自己被點(diǎn)擊, 顯示的也是Widget3的幫助.
我們需要看到的是: Widget7和Widget3, 顯示幫助的方式可能完全不同, 這原因并非因?yàn)閃idget7對(duì)應(yīng)了一個(gè)既定的傳入信息而Widget3對(duì)應(yīng)了另外一個(gè), 而是因?yàn)閃idget的畫圖方式可能和Widget3不同; 即這種不同不是對(duì)應(yīng)于外部對(duì)象, 而是職責(zé)鏈上對(duì)象本身的特性所確定的. 這就決定了, 在運(yùn)行時(shí), 對(duì)于某一信息, 我們改變了這一信息的處理方式. 沒人處理的方式一般也不是返回false, 而是交給最終的一個(gè)DefaultHandler, 做默認(rèn)操作; 這表面看跟直接返回沒啥區(qū)別, 每次還必須將DefaultHandler接到職責(zé)鏈尾端, 但實(shí)質(zhì)上保證了處理方式的統(tǒng)一.
另外, GoF的例子中, 一個(gè)對(duì)象是否響應(yīng)職責(zé)鏈, 也是不固定的, 這話看著和上面重復(fù), 其實(shí)這是另一個(gè)不固定: 任何一個(gè)從基類繼承下來的對(duì)象, 比如上面這些Widget, 如果它被設(shè)置了幫助, 當(dāng)它被點(diǎn)擊就會(huì)響應(yīng), 如果沒有設(shè)定幫助(默認(rèn)值), 就應(yīng)該由它傳遞給更下層的一個(gè). 這個(gè)情況下Widget7響應(yīng)這個(gè)請(qǐng)求, 另一個(gè)情況也許就不響應(yīng)了, 這只和是否給Widget7設(shè)置了幫助文本有關(guān). 即: 判斷是不是響應(yīng)的條件, 并非傳入對(duì)象持有的信息(事實(shí)上GoF的例子根本沒有傳入對(duì)象), 而是由職責(zé)鏈上的對(duì)象自己持有的信息來確定.在GoF的說法里, 非常關(guān)鍵的一個(gè)詞, 就是上下文相關(guān), 這才是職責(zé)鏈的精髓所在, 而傳遞這一形式, 僅僅是具體做法罷了.
最后, 考慮這個(gè)窗口平面的例子, 我們用小問號(hào)點(diǎn)擊的Widget, 不一定是處于鏈表頭的對(duì)象, 我們的點(diǎn)擊可以落在鏈表中任何一層上任何一個(gè)對(duì)象所對(duì)應(yīng)的范圍內(nèi), 所以鏈表中每一個(gè)對(duì)象都肯能而且可以成為入口. 按照原文例子的用法, 所有的請(qǐng)求都只能從鏈表頭也就是最上層進(jìn)去, 這和DP95上所描述的意圖和結(jié)構(gòu)完全不符, 在GoF描述的職責(zé)鏈功能和用法中, 每一個(gè)具體子類都可能響應(yīng)請(qǐng)求, 這是由輸入動(dòng)態(tài)決定的, 如果只從頭部進(jìn)去, 只不準(zhǔn)哪個(gè)不該負(fù)責(zé)的對(duì)象就進(jìn)行了不正確響應(yīng): 比如點(diǎn)擊的Widget3, 請(qǐng)求卻讓W(xué)idget1給截獲了.
不同的子類, 只是行為不同, 而不代表該子類從根本上只可以處理它對(duì)應(yīng)的信息, 不能處理其它信息, 即不存在(信息1 --> 行為1)這樣的對(duì)應(yīng)關(guān)系; 每一個(gè)行為都應(yīng)該可以處理任意一種信息, 子類改變的就只是處理方式, 而到底哪一個(gè)用什么方式處理, 則是動(dòng)態(tài)的根據(jù)狀態(tài)決定的. 正是因?yàn)槲覀儾恢滥骋粚?duì)象, 是否會(huì)處理這個(gè)信息, 所以我們就無法應(yīng)用表模式, 這樣就需要職責(zé)鏈模式來解決.這才是23種而不是22種設(shè)計(jì)模式的原因.
比如這樣的形式:
XxxBindingConstraint x = new XxxBindingConstraint();
x.SetParent(previousBindingConstraint);
x.AddNames({"Basic", "WS", "xxx".});
很顯然, 如果這樣修改原文的例子, 雖然每個(gè)對(duì)象都能響應(yīng)請(qǐng)求了, 卻不能正確執(zhí)行: 但因?yàn)槠湓O(shè)計(jì)目的緣故, 比如Basic對(duì)應(yīng)的實(shí)現(xiàn)只并不負(fù)責(zé)處理WS, 只能等著拋出異常, 根本不就不符合這個(gè)意義:
DP95第五章開頭
Chain of Responsibility(5.1)....,根據(jù)運(yùn)行時(shí)刻情況任一候選者都可以響應(yīng)相應(yīng)的請(qǐng)求.
關(guān)于從鏈條中間開始響應(yīng)請(qǐng)求倒是不需要改, 只是這一行為根本無法做出: 因?yàn)檫@個(gè)設(shè)計(jì)從根本上講只能夠從頭部遍歷到那個(gè)屬于他的真命天女, 而并非由運(yùn)行時(shí)輸入所指定的那個(gè)開始找一個(gè)最合適的對(duì)象. 所以我們可以說, 這個(gè)例子只是徒具鏈表的形式, 卻根本沒有考慮鏈表更適合哪些情況, 在那些情況下如何發(fā)揮正面作用的; 無論這一設(shè)計(jì)實(shí)現(xiàn)的多么完美, 它相比其它選擇, 更多的是擔(dān)負(fù)了不該有的負(fù)面效果. 拋開是不是明白或誤解了什么設(shè)計(jì)模式這樣毫無重要性的事情, 這在我看來就像在過去經(jīng)常提到的, 是缺乏對(duì)事物的正確分析的緣故. 這一前提, 才是做出良好設(shè)計(jì)的唯一前提, 哪怕你都不知道設(shè)計(jì)模式是啥, 甚至連面向?qū)ο髱讉�(gè)字怎么寫都不知道.
多說一句, 對(duì)于GoF的例子, 其實(shí)也存在著很多粗陋之處(過于簡單就不算了); 比如是不是HasHelp, 由基類提供一個(gè)方法判斷, 但是如果HasHelp()傳回false, 由咱們實(shí)現(xiàn)的子類來轉(zhuǎn)發(fā). 這個(gè)模型產(chǎn)生了一個(gè)不一致性: 如果基類的HasHelp()認(rèn)為沒有Help, 但其實(shí)你根本沒有用基類這個(gè)邏輯, 按照子類的邏輯是有Help的所以你就直接響應(yīng)了呢? 于是為了消除這個(gè)不一致性, 我們實(shí)現(xiàn)子類時(shí)就不得不給基類提供信息, 這就可能會(huì)增加不必要的繁文縟節(jié). 只是這些不完美, 可以理解為示例的不嚴(yán)謹(jǐn), 總體來說是沒有任何大的漏洞的.
再看看原帖作者的例子: 每一個(gè)傳入的對(duì)象, 有一個(gè)明確的接收者; 鏈上除這個(gè)明確接收者之外的其它對(duì)象, 絕不會(huì)處理請(qǐng)求, 而這個(gè)明確的接收者, 是否處理某請(qǐng)求這一要素是固定的. 也就是說, 鏈上如果沒有這個(gè)明確的接收者, 該請(qǐng)求不會(huì)被處理; 而不是因?yàn)殒溕系慕邮照邆冊(cè)谶\(yùn)行時(shí)刻根據(jù)具體情況判斷是否響應(yīng)這個(gè)請(qǐng)求, 從而改變響應(yīng)請(qǐng)求所執(zhí)行的行為. 這樣的用法, 半點(diǎn)職責(zé)鏈的獨(dú)有好處也得不到, 只能說形似職責(zé)鏈, 實(shí)則表模式, 而且由于是鏈表, 就變成了負(fù)擔(dān)職責(zé)鏈開銷的策略模式.
怪怪設(shè)計(jì)模式第一反律: 可以找出對(duì)應(yīng)關(guān)系的, 不要使用鏈表, 如果硬以傳遞的方式成鏈, 也不能叫做職責(zé)鏈, 只能叫做對(duì)象鏈表. 職責(zé)鏈?zhǔn)且桓溕厦恳画h(huán)節(jié)皆可響應(yīng), 但不一定響應(yīng); 不是只有一個(gè)固定響應(yīng), 其它負(fù)責(zé)傳遞; 歸根結(jié)底, 是整條鏈有機(jī)的負(fù)責(zé)一個(gè)響應(yīng)一個(gè)請(qǐng)求, 而不是一個(gè)鏈表中某一對(duì)象一個(gè)人在戰(zhàn)斗, 職責(zé)是鏈的職責(zé)而不是某一對(duì)象的職責(zé). 否則這條鏈除了因?yàn)閭鹘y(tǒng)鏈表的傳遞而增加了負(fù)擔(dān)又有何意義?
什么時(shí)候該用職責(zé)鏈, 請(qǐng)自己思考, 但我們完全可以做出什么時(shí)候不要使用職責(zé)模式的判斷:
1、當(dāng)一個(gè)方法的傳入?yún)?shù)將成為分支語句的判斷條件時(shí)；
2、當(dāng)每一個(gè)分支的職責(zé)相對(duì)獨(dú)立，且邏輯較為復(fù)雜時(shí)；
3、當(dāng)分支條件存在擴(kuò)展的可能時(shí)。
總而言之, 只要你看見"分支"二字, 請(qǐng)不要使用職責(zé)模式.
我們深入一下這個(gè)問題的實(shí)質(zhì)的話, 就會(huì)發(fā)現(xiàn), 因?yàn)檎l對(duì)誰響應(yīng)這個(gè)對(duì)應(yīng)關(guān)系, 是在運(yùn)行之前就確定的, 所以最適合的方式是使用表模式. 由此我們可以得出:
怪怪設(shè)計(jì)模式第一推廣: 可以找出對(duì)應(yīng)關(guān)系的, 優(yōu)先考慮表模式; 看見"分支"二字, 優(yōu)先考慮策略模式.
最后我們?cè)倏匆幌略髡叩淖罴褜?shí)踐:
引用(錯(cuò)誤! 見后)1、應(yīng)盡量將職責(zé)鏈模式的抽象定義為抽象類，而不要定義為接口。這樣有利于一些公共邏輯的重用。
2、應(yīng)在實(shí)現(xiàn)職責(zé)鏈模式的同時(shí)，提供創(chuàng)建職責(zé)鏈的工廠類。
關(guān)于1, GoF當(dāng)初是抽象類, 但是其實(shí)接口并不是不可以. 如果你想細(xì)究這個(gè)問題, 可以看上面關(guān)于GoF例子瑕疵的討論, 來思考父類集中操作有多大意義. 但記住請(qǐng)先翻DP95, 了解清楚那個(gè)例子. 有沒有抽象類, 關(guān)鍵還在于抽象類合不合適:
怪怪第一哲學(xué)定律: 一切決定都是交換.
如果你公共操作很多, 那你就付出抽象類站位的代價(jià)(提示:DP95的代碼是C++, 可以多繼承); 如果你的其它設(shè)計(jì)需要基類, 就要付出打字的代價(jià). 這兩者可以兼得嗎? 答案見文章末尾注釋一.
關(guān)于2, 完全不靠譜. DP95上說的非常清楚, 職責(zé)鏈要解決的一個(gè)問題就是, 鏈條上單元的動(dòng)態(tài)改變. 拿上面的Widget的例子來說, 難道我們應(yīng)該為每種不同排列順序, 都搞個(gè)工廠方法? 不同類別的Widget們只要能互相嵌套, 其排列組合有多少是可以預(yù)期的. 另外, 真正的職責(zé)鏈, 接收請(qǐng)求的對(duì)象可以是鏈條中的任何一個(gè)具體子類, 而用了Factory, 我們只能從頭部傳入信息, 職責(zé)鏈原本具有的行為就不正常了, 討論見上面Widget那部分.
在文章末尾, 我想嚴(yán)肅的說兩句多余的話: 我一直在呼吁的是, 如果作者們不確定自己的理解, 請(qǐng)考慮對(duì)博文讀者的影響有多大可能性是壞的; 寫東西時(shí), 也不要太過自信, 如金科玉律; 不如以提問的方法說, 比如: "我是這樣想的, 大家看對(duì)不對(duì)? "; 更不要著急在得到驗(yàn)證前, 隨便將自己的文章放傳播到更廣泛的地方上去, 把炸彈變成原子彈.
不過我仍然覺得, 今天這塊板磚有點(diǎn)太大了, 因?yàn)槲夷靡槐驹O(shè)計(jì)模式書籍的作者當(dāng)作了例子. 我想這篇文章是dudu都不愿看到的(小人之心度君子之腹), 畢竟該作者的大作屬于博客園系列. 我其實(shí)非常猶豫發(fā)不發(fā)該文, 因?yàn)檎f實(shí)在的, 別人對(duì)設(shè)計(jì)模式會(huì)不會(huì)誤解, 和我一樣的初學(xué)者會(huì)不會(huì)受誤導(dǎo), 跟我有屁關(guān)系? 我又不是以技術(shù)宣傳為生存手段的, 況且如果我打算寫書, 恐怕這篇文章連出版商都不愿意看到; 恐怕他們更愿意的是別人自己寫自己的, 別涉及他們的作者的文章; 哪個(gè)出版商會(huì)對(duì)沒事得罪人的人感興趣? 我之所以意識(shí)到這些問題, 卻沒有去換個(gè)例子, 也有考慮: 我一直提倡的是, 無論誰寫的是黑紙白字幾十塊一本, 還是隨便討論瞎說幾句, 大家最好都自己思考后再說; 從這個(gè)意義上講, 原文作者的情況作為例子倒是最合適的.
且不說招一大片人反感的問題, 作為一個(gè)軟件從業(yè)人員和潛在競爭對(duì)手, 對(duì)我來說, 別人走越多彎路, 是不是對(duì)我越有益呢? 我偶爾會(huì)思考這個(gè)問題, 也希望得到大家的答案.
----------------------------------------
注釋一: 我的答案是可以; 這需要額外的學(xué)習(xí)和外部條件, 和引入一個(gè)新模式, Gasket, 即墊片模式; 這個(gè)模式也要交換從而付出很大的代價(jià):該模式有擴(kuò)散的特性, 導(dǎo)致你寫程序方方面面有徹底的變化, 甚至是沒有接觸過的方式; 所以也要下功夫?qū)W很多新東西.
P.S. 不用Baidu和Google了, 該模式是我自娛自樂的一個(gè)野路子, 在經(jīng)過我自己嚴(yán)格檢驗(yàn)前, 不打算發(fā)表(而且對(duì)于很多固執(zhí)的人而言肯定不愿意付出某些代價(jià)去交換), 先賣個(gè)關(guān)子吧.
|
