Ch1 policies
wychi
我先來放第一炮好了
看完第一章後,
Policy-Based Class Design 的彈性的確讓人相當欣賞
但是,倉促之間也不知道要討論些什麼
所以我先問一個跟技術沒關的,我想請教的是,
請問有沒有其它類似的設計思維 或 完全不同的思維
OOD Tsen
一個程式內部有IO，記憶體，錯誤處理，流程，等多維度
結果按照其中一個維度抽象化，結果其他維度還是將class牢牢的串在一起
結果還是不能做到軟體元件自由可攜的效果
只是讓程式碼變成更難懂的怪獸
wychi
這樣確實是很大的問題
理想與現實總是有差距的
在我的case中,遇到的情況是
切出太多的policy,
東拼西湊的把ap建起來
感覺不太划算
milochen (陳文輝 Chen,Wen-Hui)
大概
看了一下，發現自己真的不太能夠容入它的觀念，
分享一下自己看完後的心得 >"<
以下我對第一章裡，1至5節的心得分享，
歡迎討論一下，也許大家討論的情況下就能夠懂了。
如果有人可以引導的話，那就更感恩了 ^^。
1.1 The Multiplicity of Software Design
心得：看不懂
1.2 The Failure of the Do-It-All Interface
問題：什麼是 A gap grows between "syntactically valid' and
'semantically valid'?
1.3 Multiple Inheritance to the Rescue
心得：光看標題就整個不懂
1.4 The Benefit of Templates
心得：是一個多重繼承 跟
Template的機制的分析，但看不懂它的分析
作者藉由這分析後，建議說
這兩個東西組合起來在寫Library會比較有彈性。
它的分析似乎很重要，大概知道 多重繼承 與
Template機制 這兩個東西自己要多多修練。
1.5 Policies and Policy Classes
心得：
以前我們都是為一個class「定義member
function」，然後遵循定義來 「實現member function」。
它Policy
的思維是說，可以換個方式是說，把原本「定義member
function」的方式，改成是
「定義Policy」，而我們照著這Policy的定義則可以知道這個Policy
主要是在定義 「要作什麼事」。
就跟「定義member
function」一樣是在定義「要作什麼事」。
「實現Policy」的方式是由我們可以寫個policy class 來
實現「所要作的事」
就好像「實現member function」是 在
實現「所要作的事」一樣。
如此一來，原本member function的定義與實現
就變成是以class為單位的定義與實現。
但是譬如像Creator 的policy
class就有像課本第8頁的那三種 OpNewCreator,
MallocCreator與PrototypeCreator。
在Library code只寫到說
WidgeManager裡面會用到CreationPolicy，
那Application code是由使用Library Code的人來寫的嗎?
似乎寫應用程式的人可以決定
那一個Policy 要採用那個 Policy Class來實現。
但是PrototypeCreator這policy
class裡面還宣告了像GetPrototype()這個member function。
好怪的事喔!! 那 像 PrototypeCreator::GetPrototype() 這個member
function到底是誰要呼叫的呀??
到底 「使用Library的人所該扮演的角色 跟
創造Library的人所該扮演的角色」
是不是 在 Policy 這概念 出來後，有跟以前
不太一樣呀??
以前是 把class 的member function定的清清楚楚，
而使用者則是 完全依照member function的定義來使用。
那Policy 的觀念裡，也是一樣嗎? 還是有所不同呢???
wychi
milochen (陳文輝 Chen,Wen-Hui) 寫道：
> 第一章的 Policy-Based Class Design
> 大概
> 看了一下，發現自己真的不太能夠容入它的觀念，
> 分享一下自己看完後的心得 >"<
>
> 以下我對第一章裡，1至5節的心得分享，
> 歡迎討論一下，也許大家討論的情況下就能夠懂了。
> 如果有人可以引導的話，那就更感恩了 ^^。
>
> 1.1 The Multiplicity of Software Design
> 心得：看不懂
>
> 1.2 The Failure of the Do-It-All Interface
> 問題：什麼是 A gap grows between "syntactically valid' and
> 'semantically valid'?
這句中在中譯本應該是
"程式員可能會因為一些 語法有效 但 語意無效
的程式而破壞了整個設計"
> 1.3 Multiple Inheritance to the Rescue
> 心得：光看標題就整個不懂
在概念上
multiple inheritance可以用來解決設計多樣性的問題
根據某種規則我們可以將 功能(functions)
劃分成若干種類(class),
當我們的目標class T 可能同時想要表示 class A
全部/部分的功能 及 class B全部/部分的功能
透過multiple inheritance的宣告來表示 (class T : public A,
public B)
如此就可以讓class T同時擁有 class A 跟 class B的特性
所以當看到 class T , 我可以任意把它當成class A or class B
從此出發可以解決設計時面臨的多樣性選擇問題
wychi
EricWang
1.policy幾乎可以跟 stratecy pattern劃上等號
不過我認為Policy並不好用，除非你真的很懂
1.多重繼承，除非你很搞的懂，否則很容易出錯及濫用
2.繼承就應該要遵守 liskov
principle，不過這是一件很難的事
到最後一定又會變成濫用...
現在的人都不用繼承以及"多重"繼承，作者卻反其道而行
不過那是他老大做的Policy在語意上夠抽象，不過如果要語意要往下下去的話，
Policy這套可能就行不通了...
wychi
EricWang 寫道：
> On 1月3日, 下午12時09分, "wychi" <cweny...@gmail.com> wrote:
> > 大家好,
> > 我先來放第一炮好了
> >
> > 看完第一章後,
> > Policy-Based Class Design 的彈性的確讓人相當欣賞
> > 但是,倉促之間也不知道要討論些什麼
> >
> > 所以我先問一個跟技術沒關的,我想請教的是,
> > 請問有沒有其它類似的設計思維 或 完全不同的思維
>
> 1.policy幾乎可以跟 stratecy pattern劃上等號
>
> 不過我認為Policy並不好用，除非你真的很懂
> 1.多重繼承，除非你很搞的懂，否則很容易出錯及濫用
> 2.繼承就應該要遵守 liskov
> principle，不過這是一件很難的事
> 到最後一定又會變成濫用...
>
>
>
> 現在的人都不用繼承以及"多重"繼承，作者卻反其道而行
^^^^^^^^^^^^^^??
不能理解, 為何說不用繼承??
多重繼承帶來的複雜 遠大於 我們可以得到好處,
所以不用"多重繼承",我可以理解
但是
不用繼承,不就把OO中的一個重要且好用的部份直接捨棄?
那, 請問取而代之是什麼??
> 不過那是他老大做的Policy在語意上夠抽象，不過如果要語意要往下下去的話，
這句能多做點解釋嗎??
> Policy這套可能就行不通了...
EricWang
合成較繼承彈性較佳，原因是在Run-time
時合成可抽換，繼承不可
(但C++的 template programming技術可以)
若對這塊有興趣的話，可以去看head first design pattern
第一章
有生動的故事告訴你"多用合成，少用繼承"這個原則...
在Java那邊，繼承多通常用於"限定子類別的一種契約(comtract)"
而不是藉由繼承，而達到功能上的reuse
在單一繼承的世界裡(如java ,
C#等)，他是不能使用policy這招的
因為他們對於"泛型"的支援不夠，java
5.0才開始支援泛型
C++因為泛型的關係，可以在Compile
time抽換Policy，但Java不行
不過相對的使用合成一樣可以達到目的
policy與stratecy pattern很像，作法不同但目的相同
stratecy pattern是用"合成"做的，你可以參考看看
而做policy的語意要夠抽象的意思是
一堆policy
class如果要在任意環境中組裝起來還可以run的話
他所帶的語意就必須夠完整也夠獨立
你如果一個Policy做的太detail的話，很可能在其他的環境上不能run
我指的detail是"語意上的"，也就是說，語意上要切的開
而我說liskov其實說錯了，一個在run time
時可以抽換的繼承體系必須要遵守liskov
在這邊並不符合這種狀況，你可以忘了他...
wychi
"多用合成，少用繼承", 的確是很正確的觀念
就像你提到的
"
在Java那邊，繼承多通常用於"限定子類別的一種契約(comtract)
而不是藉由繼承，而達到功能上的reuse
"
單單只是為了function
reuse而使用繼承,實在是個很大的誤用
但 在我的認知裡
合成跟繼承並不應該拿來對比,
因為他們要描述的概念並不一樣
合成 是來說明 has-a 的關係
繼承 是來說明 is-a 的關係
如此要說 不用繼承也太過偏頗
(不要用多重繼承,我可是非常讚同)
另外
我想在c# or java應該也是可以用policy-based 的方式來設計
當然不是用多重繼承的方式 ,
而是如你所說的用"合成"的方式來達成
不過會有一些限制就是了
(這地方我覺得可以多多討論一下)
"
而做policy的語意要夠抽象的意思是
一堆policy
class如果要在任意環境中組裝起來還可以run的話
他所帶的語意就必須夠完整也夠獨立
你如果一個Policy做的太detail的話，很可能在其他的環境上不能run
我指的detail是"語意上的"，也就是說，語意上要切的開
"
我想,這就是我在操作上遇到的問題,
花了很大的功夫找出一個個正交的policy ,
但確只能用在一個project
換了一個project,又要重新找出不同的policy
覺得有殺雞用牛刀的感覺
wychi
milochen (陳文輝 Chen,Wen-Hui) 寫道：
說實在的, 我被你搞混了
看不懂你想表達的
不過我可以告訴你
PrototypeCreator::GetPrototype() & PrototypeCreator::SetPrototype()
在這個地方用不到
可能是為了其它的目的而存在,
至於誰要呼叫,什麼時候呼叫的這回事
就看設計者的心情吧
(在書中也是有提到啊 p.9 中段)
milochen (陳文輝 Chen,Wen-Hui)
最近我在loki下載的了式庫裡面，裡面有個文件講到了一個網址
http://www.ddj.com/dept/cpp/184403784
裡面主要是講到 A Policy-Based basic_string
我覺得它前面先花點時間，提出他設計時的想法，然後因為這些想法
而接著才使用 Policy-Based 的方式來設計。
目前還沒有說整個看的很深入了解，不過
我覺得以它這個設計觀念切入，用Policy class 這種設計的方式，我覺得
是直觀且明白的。
看了這個例子以後，我似乎比較有感覺了。
不知道大大們看了以後，是否對於Policy Class這種方式的意義
是不是就如小弟回文上所述的意義?? 謝謝
> > > 只是讓程式碼變成更難懂的怪獸- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -