討論區快速選單
知識庫快速選單
軟體開發過程中有哪些資安漏洞? 掌握Salesforce雲端管理秘訣 政府補助!學嵌入式+物聯網
[ 回上頁 ] [ 討論區發言規則 ]
多重繼承有什麼好處呢?
更改我的閱讀文章字型大小
作者 : (Benjamin)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/10/12 下午 04:54:54
似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
所以想問看看多重繼承有什麼好處呢?
作者 : (鹹魚)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/10/13 上午 02:12:13
>似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
>所以想問看看多重繼承有什麼好處呢?

我個人認為物件導向的繼承設計上是有缺陷的~
繼承的目的無非是為了程式碼的重用~
雖然出發點很好~
但是在設計上個人認為實在是困難重重~
原因是要設計一個好的基底類別相當不容易~
因為物件繼承的架構總是以一總集合的方式來描述~
打個比方~
人是一種動物,狗是一種動物,豬是一種動物...~
我們可以清楚看到"動物"是父類別,而人,狗,豬是子類別~
這些子類別都具有父類別一些特性~
於是屬於"動物"特性的程式碼就可以在動物類別內被實做~
而在子類別內被重複使用~
但是在現實世界裡~
並不是先有動物再有人的~
而是先有了很多不同特性的東西~
然後我們再將其分類而將某些特性的東西分類到動物這個集合裡的~
所以說我們如何在還沒有任何具動物特性的東西出現前就發明動物呢?
這點讓我覺得繼承在設計上很困難(也許用起來容易)~

至於多重繼承就是將許多不同特性的類別整合起來~
例如某樣新的東西同時繼承了鞋子與電話~
於是出現了可以打電話的鞋子~
當你在球場上打球時鞋子響了~
於是就可以把鞋子接起來(也許有點味道)~
並和朋友討論晚上要去那吃飯~
如此先進的鞋子去那找ㄚ~
但是多重繼承在實做上有些不好的地方~
像是名稱衝突(光這點就很嚴重了)~
像我上面舉的例子其實還不太容易發生衝突~
但是如果是某樣新的多功能鞋同時繼承了籃球鞋與慢跑鞋了話~
事情就大條了~
多功能鞋的鞋帶到底要用籃球鞋的好呢還是慢跑鞋~
跑的時候到底是要慢跑鞋的輕盈呢還是籃球鞋的高保護性~
於是就開始打架了~
因為只要是繼承來的東西都會同時存在的~
任何的特性都不會被埋沒~
所以我覺得多重繼承很不好~
因為往往繼承的東西都太具象(抽象的反意)了~
總之,多重繼承是bug的泉源~

我覺得Java在這點上就做的很棒~
她不支援多重繼承而支援介面~
雖然可以打電話的鞋子有點怪~
但是為鞋子加上通訊功能又何嘗不可ㄋ?
甚至還可以裝上翅膀呢!!
因為一個具象的物件實在不適合再加上另一個具象的物件了~
但是為一個具象的物件加上一個抽象的功能這個主意倒是不錯~
這表示鞋子依然是鞋子~
但是功能無限~
這不就是我們想要的嗎?
誰會希望犀牛生出一個人來?
太怪異了吧!

以上僅是我個人的看法~









作者 : (Marvin)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/10/14 上午 01:51:35
>似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
>所以想問看看多重繼承有什麼好處呢?

正好學了一些PowerBuilder, 所以發表一些個人看法:
1. 據某些書(開發工具的教科書)所說, 多重繼承的主要
    著眼點在於降低程式碼的Maintenance work, 以及增
    進所謂的封裝性(encapsulation ?)與程式開發速度.
    以前的程式沒有繼承的特性, 所以在歷經多次修改後
    就越難維護.

2. 而且多重繼承主要可以增進團隊開發的速度與程式碼
    保密性. 舉例來說, 每個programmer的熟練度與專精
    領域各有不同, 由資深的(或不同專長)程式設計師寫
    基礎元件, 較資淺的programmer組合使用介面, 而透
    過各種管制機構, 可以使關鍵技術不外流.

3. 其實寫了很多商業程式之後, 發現資料結構與運算法則
    更需要去費心制定(在考慮未來需求的擴充彈性上), 能
    善用好了元件可以少花些心思在使用介面的debug上.

    當然了, 缺點不是沒有, 但是最多人碰到的瓶頸就是寫
習慣了結構化語言, 要他找繼承關係就很痛苦(尤其是說明
文件不足的情況下). 而且開發工具的好壞也決定了OOP(團
隊開發程式碼)的經驗是否痛苦. Mm....另外, 目前碰上的
OOP語言都免不了有著耗用資源甚鉅的狀況, 控制不好還
會讓程式掛掉. 看個人習慣吧.....



    
作者 : (easylook3d)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/10/14 下午 08:25:21
>>似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
>>所以想問看看多重繼承有什麼好處呢?

>正好學了一些PowerBuilder, 所以發表一些個人看法:
>1. 據某些書(開發工具的教科書)所說, 多重繼承的主要
> 著眼點在於降低程式碼的Maintenance work, 以及增
> 進所謂的封裝性(encapsulation ?)與程式開發速度.
> 以前的程式沒有繼承的特性, 所以在歷經多次修改後
> 就越難維護.

>2. 而且多重繼承主要可以增進團隊開發的速度與程式碼
> 保密性. 舉例來說, 每個programmer的熟練度與專精
> 領域各有不同, 由資深的(或不同專長)程式設計師寫
> 基礎元件, 較資淺的programmer組合使用介面, 而透
> 過各種管制機構, 可以使關鍵技術不外流.

>3. 其實寫了很多商業程式之後, 發現資料結構與運算法則
> 更需要去費心制定(在考慮未來需求的擴充彈性上), 能
> 善用好了元件可以少花些心思在使用介面的debug上.

> 當然了, 缺點不是沒有, 但是最多人碰到的瓶頸就是寫
>習慣了結構化語言, 要他找繼承關係就很痛苦(尤其是說明
>文件不足的情況下). 而且開發工具的好壞也決定了OOP(團
>隊開發程式碼)的經驗是否痛苦. Mm....另外, 目前碰上的
>OOP語言都免不了有著耗用資源甚鉅的狀況, 控制不好還
>會讓程式掛掉. 看個人習慣吧.....




如果OLE能完全自動化, 自然像Java等程式便無須為繼承傷腦筋
作者 : (JAMES)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/11/6 下午 03:53:28
>>>似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
>>>所以想問看看多重繼承有什麼好處呢?
>>
>>正好學了一些PowerBuilder, 所以發表一些個人看法:
>>1. 據某些書(開發工具的教科書)所說, 多重繼承的主要
>> 著眼點在於降低程式碼的Maintenance work, 以及增
>> 進所謂的封裝性(encapsulation ?)與程式開發速度.
>> 以前的程式沒有繼承的特性, 所以在歷經多次修改後
>> 就越難維護.
>>
>>2. 而且多重繼承主要可以增進團隊開發的速度與程式碼
>> 保密性. 舉例來說, 每個programmer的熟練度與專精
>> 領域各有不同, 由資深的(或不同專長)程式設計師寫
>> 基礎元件, 較資淺的programmer組合使用介面, 而透
>> 過各種管制機構, 可以使關鍵技術不外流.
>>
>>3. 其實寫了很多商業程式之後, 發現資料結構與運算法則
>> 更需要去費心制定(在考慮未來需求的擴充彈性上), 能
>> 善用好了元件可以少花些心思在使用介面的debug上.
>>
>> 當然了, 缺點不是沒有, 但是最多人碰到的瓶頸就是寫
>>習慣了結構化語言, 要他找繼承關係就很痛苦(尤其是說明
>>文件不足的情況下). 而且開發工具的好壞也決定了OOP(團
>>隊開發程式碼)的經驗是否痛苦. Mm....另外, 目前碰上的
>>OOP語言都免不了有著耗用資源甚鉅的狀況, 控制不好還
>>會讓程式掛掉. 看個人習慣吧.....
>>
>>
>>
>>
>如果OLE能完全自動化, 自然像Java等程式便無須為繼承傷腦筋



多重繼承雖然益處很多,但為何 JAVA & C++ Builder ....等編譯器不支援ㄋ?....其實它有一個很重要的致命點......(賣個關子)......所以很多的編譯器都不支援它以強迫程式設計師去避開這種寫法...

但如果這樣就沒辦法作到類似多重繼承的功能嗎?答案是否定的...
譬如說 JAVA 就可用"介面"的關念來達到多重繼承的功能...^^
不信嗎?試試看ㄅ.....

作者 : (JAMES)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/11/6 下午 04:48:29
>>>>似乎很多語言都沒有支援多重繼承, 那可能多重繼承有什麼缺點吧?
>>>>所以想問看看多重繼承有什麼好處呢?
>>>
>>>正好學了一些PowerBuilder, 所以發表一些個人看法:
>>>1. 據某些書(開發工具的教科書)所說, 多重繼承的主要
>>> 著眼點在於降低程式碼的Maintenance work, 以及增
>>> 進所謂的封裝性(encapsulation ?)與程式開發速度.
>>> 以前的程式沒有繼承的特性, 所以在歷經多次修改後
>>> 就越難維護.
>>>
>>>2. 而且多重繼承主要可以增進團隊開發的速度與程式碼
>>> 保密性. 舉例來說, 每個programmer的熟練度與專精
>>> 領域各有不同, 由資深的(或不同專長)程式設計師寫
>>> 基礎元件, 較資淺的programmer組合使用介面, 而透
>>> 過各種管制機構, 可以使關鍵技術不外流.
>>>
>>>3. 其實寫了很多商業程式之後, 發現資料結構與運算法則
>>> 更需要去費心制定(在考慮未來需求的擴充彈性上), 能
>>> 善用好了元件可以少花些心思在使用介面的debug上.
>>>
>>> 當然了, 缺點不是沒有, 但是最多人碰到的瓶頸就是寫
>>>習慣了結構化語言, 要他找繼承關係就很痛苦(尤其是說明
>>>文件不足的情況下). 而且開發工具的好壞也決定了OOP(團
>>>隊開發程式碼)的經驗是否痛苦. Mm....另外, 目前碰上的
>>>OOP語言都免不了有著耗用資源甚鉅的狀況, 控制不好還
>>>會讓程式掛掉. 看個人習慣吧.....
>>>
>>>
>>>
>>>
>>如果OLE能完全自動化, 自然像Java等程式便無須為繼承傷腦筋
>>


>多重繼承雖然益處很多,但為何 JAVA & C++ Builder ....等編譯器不支援ㄋ?....其實它有一個很重要的致命點......(賣個關子)......所以很多的編譯器都不支援它以強迫程式設計師去避開這種寫法...

>但如果這樣就沒辦法作到類似多重繼承的功能嗎?答案是否定的...
>譬如說 JAVA 就可用"介面"的關念來達到多重繼承的功能...^^
>不信嗎?試試看ㄅ.....




在此就舉個例子說明多重繼承的致命點之一..

class base
{
 int mem1;
   ......
};

class mother : virtual public base
{
.....
};

class father : virtual public base
{
....
};

class child : public mother,public father
{
};


1.main()
2.{
3. child *ptrChild=new child();
4. int getdata=ptrChild->mem1; //此行所指 DATA 是指向那ㄋ?
     //是 base 的 mem1 嗎? or 是
     //mother or father 的...

    ....
5. ptrChild->mem1=12; //
    .......
    }

如第 4,5 行所示.....到底該指向那一個ㄋ?...大家想想ㄅ...^^

答案一定是無法確定的....
故如果你是寫編譯器的人你會將他編為那一個ㄋ?....
第一層(base )嗎?or 第二層嗎(mother ,father 其中一個)?
傷腦筋...@@|||...乾脆不支援好ㄌ...
上面的例子如果能編譯通過則產生出來的 bug 是非常可怕的..
這種 bug 在一個很大的 team 中要如何查ㄋ?..
恐佈ㄛ...恐怖的不得了ㄛ....

剛剛有說到 JAVA 就可用"介面"的關念來達到多重繼承的功能;
C++不行嗎?當然可以.....就用"組合"ㄅ..
JAMES
作者 : (Marvin)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/11/10 下午 11:25:18
>>
>>
>>多重繼承雖然益處很多,但為何 JAVA & C++ Builder ....等編譯器不支援ㄋ?....其實它有一個很重要的致命點......(賣個關子)......所以很多的編譯器都不支援它以強迫程式設計師去避開這種寫法...
>>
>>但如果這樣就沒辦法作到類似多重繼承的功能嗎?答案是否定的...
>>譬如說 JAVA 就可用"介面"的關念來達到多重繼承的功能...^^
>>不信嗎?試試看ㄅ.....
>>
>>


>在此就舉個例子說明多重繼承的致命點之一..

>class base
>{
> int mem1;
> ......
>};

>class mother : virtual public base
>{
>.....
>};

>class father : virtual public base
>{
>....
>};

>class child : public mother,public father
>{
>};


>1.main()
>2.{
>3. child *ptrChild=new child();
>4. int getdata=ptrChild->mem1; //此行所指 DATA 是指向那ㄋ?
> //是 base 的 mem1 嗎? or 是
> //mother or father 的...

> ....
>5. ptrChild->mem1=12; //
> .......
> }

>如第 4,5 行所示.....到底該指向那一個ㄋ?...大家想想ㄅ...^^

>答案一定是無法確定的....
>故如果你是寫編譯器的人你會將他編為那一個ㄋ?....
>第一層(base )嗎?or 第二層嗎(mother ,father 其中一個)?
>傷腦筋...@@|||...乾脆不支援好ㄌ...
>上面的例子如果能編譯通過則產生出來的 bug 是非常可怕的..
>這種 bug 在一個很大的 team 中要如何查ㄋ?..
>恐佈ㄛ...恐怖的不得了ㄛ....

>剛剛有說到 JAVA 就可用"介面"的關念來達到多重繼承的功能;
>C++不行嗎?當然可以.....就用"組合"ㄅ..
>JAMES


雖然所學語言不同(我學PowerBuilder), 但是提供一些意見供各位
參考..........^_^

James所言的致命缺失, 在某些OOP是用function與method來作補救.
function與method大概可以這樣比喻:
function 類似物件的行為,(以擬人化來說, 就像是某個人處理事情
的行為與結果)
method 類似物件的特質.(以擬人化來說, 就像是某個人的特質,
例如2個眼睛, 1個嘴巴)

James前例所舉的child裡有2個變數 father與mother, 可視為child
這個物件的特質, AP的其他物件要讀取可以用這種方式讀取:

  child child1 // declare instance variable based on class <child>
  int getdata // declare int
....................
   getdata = Child1.father

不知道這樣回答James的多重繼承致命缺點, 是否適當?
Marvin



作者 : (yfcii)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2000/11/25 上午 11:37:08

>在此就舉個例子說明多重繼承的致命點之一..

>class base
>{
> int mem1;
> ......
>};

>class mother : virtual public base
>{
>.....
>};

>class father : virtual public base
>{
>....
>};

>class child : public mother,public father
>{
>};


>1.main()
>2.{
>3. child *ptrChild=new child();
>4. int getdata=ptrChild->mem1; //此行所指 DATA 是指向那ㄋ?
> //是 base 的 mem1 嗎? or 是
> //mother or father 的...

> ....
>5. ptrChild->mem1=12; //
> .......
> }

>如第 4,5 行所示.....到底該指向那一個ㄋ?...大家想想ㄅ...^^

>答案一定是無法確定的....
>故如果你是寫編譯器的人你會將他編為那一個ㄋ?....
>第一層(base )嗎?or 第二層嗎(mother ,father 其中一個)?
>傷腦筋...@@|||...乾脆不支援好ㄌ...
>上面的例子如果能編譯通過則產生出來的 bug 是非常可怕的..
>這種 bug 在一個很大的 team 中要如何查ㄋ?..
>恐佈ㄛ...恐怖的不得了ㄛ....

>剛剛有說到 JAVA 就可用"介面"的關念來達到多重繼承的功能;
>C++不行嗎?當然可以.....就用"組合"ㄅ..
>JAMES



既然 father and mother 都是 virtual 繼承 base, 那麼根本就沒有你所說的問題. 你所說的問題只有在 father an mother 二個之中有任一or全部都不是virtual 繼承 base 才會發生.



作者 : (雞婆)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2001/3/27 下午 11:35:24
>>
>>在此就舉個例子說明多重繼承的致命點之一..
>>
>>class base
>>{
>> int mem1;
>> ......
>>};
>>
>>class mother : virtual public base
>>{
>>.....
>>};
>>
>>class father : virtual public base
>>{
>>....
>>};
>>
>>class child : public mother,public father
>>{
>>};
>>
>>
>>1.main()
>>2.{
>>3. child *ptrChild=new child();
>>4. int getdata=ptrChild->mem1; //此行所指 DATA 是指向那ㄋ?
>> //是 base 的 mem1 嗎? or 是
>> //mother or father 的...
>>
>> ....
>>5. ptrChild->mem1=12; //
>> .......
>> }
>>
>>如第 4,5 行所示.....到底該指向那一個ㄋ?...大家想想ㄅ...^^
>>
>>答案一定是無法確定的....
>>故如果你是寫編譯器的人你會將他編為那一個ㄋ?....
>>第一層(base )嗎?or 第二層嗎(mother ,father 其中一個)?
>>傷腦筋...@@|||...乾脆不支援好ㄌ...
>>上面的例子如果能編譯通過則產生出來的 bug 是非常可怕的..
>>這種 bug 在一個很大的 team 中要如何查ㄋ?..
>>恐佈ㄛ...恐怖的不得了ㄛ....
>>
>>剛剛有說到 JAVA 就可用"介面"的關念來達到多重繼承的功能;
>>C++不行嗎?當然可以.....就用"組合"ㄅ..
>>JAMES
>>


>既然 father and mother 都是 virtual 繼承 base, 那麼根本就沒有你所說的問題. 你所說的問題只有在 father an mother 二個之中有任一or全部都不是virtual 繼承 base 才會發生.

多重繼承有它絕對的價值,完全看使用在那方面,及對物件導向精神的認知,針對你所提出的例子,建議你可將 mem1的位置印出來看,比對一下你就可以知道了,還有程式設計是用寫的不是用想的.
base *Base=(base *)ptrChild;
printf("%p %p",&ptrChild->mem1,&base->mem1);

作者 : (sercocn)
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2001/4/1 下午 11:52:26

>多重繼承有它絕對的價值

1:c++提供給你多重繼承,但為要求任何人用多重繼承

2:若多重繼承百害而無一利,c++決不會有多重繼承

3:c++的iostream,fstream,ifstream,ofstream就是用多重繼承

4:多重繼承的確有其缺陷(陷阱),使用之前再想想有無其他解決方法
作者 : chenhs(tiger)
[ 貼文 7 | 人氣 793 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/7/8 下午 01:06:26
>
>>多重繼承有它絕對的價值
>
>1:c++提供給你多重繼承,但為要求任何人用多重繼承
>
>2:若多重繼承百害而無一利,c++決不會有多重繼承
>
>3:c++的iostream,fstream,ifstream,ofstream就是用多重繼承
>
>4:多重繼承的確有其缺陷(陷阱),使用之前再想想有無其他解決方法
>
小弟也贊同,其實不光是多重繼承,任何的方法都有其優缺點,單看使用的人如何去發揮長處,避開短處,這是小弟的淺見
作者 : moo(臭蟲) 貼文超過200則
[ 貼文 460 | 人氣 6646 | 評價 1190 | 評價/貼文 2.59 | 送出評價 19 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/12 上午 05:57:09

多重繼承我蠻常用的,
我舉一個用例:

假如你看了design pattern中的Command Pattern,
覺得不錯, 所以設計了一系列的XxxCommand class,
它們都以Command為base class:

class Command
{
public:
    virtual ~Command();
    virtual void Execute() = 0;
};

另一方面,
你又設計了一個模組支援Persistence,
其中律定了共通的介面:

class PersistentObject
{
public:
    virtual ~PersistentObject();
    virtual void Serialize() = 0;
    virtual void Deserialize() = 0;
};

現在, 如果你想讓所有的XxxCommand class也具備Persistent的性質,
該怎麼做呢?

也許直覺的做法就是改Command class:

class Command: public PersistentObject
{
public:
    virtual ~Command();
    virtual void Execute() = 0;
    virtual void Serialize() = 0;
    virtual void Deserialize() = 0;
};

不過, 這把其他不需要persistence的command污染了,
它們並不想看到Serialize()和Deserialize(), 卻看到了,
而且Command class也變胖了,

一個不錯的做法就是用多重繼承,
新定一個class:

class PersistentCommand: public Command, PersistentObject
{
public:
    virtual ~PersistentCommand();
    virtual void Execute() = 0;
    virtual void Serialize() = 0;
    virtual void Deserialize() = 0;
};

現在,
你有三組不同的介面,
能同時滿足三種不同的需要,
並分別提供剛剛好的介面, 不多, 也不少.
作者 : moo(臭蟲) 貼文超過200則
[ 貼文 460 | 人氣 6646 | 評價 1190 | 評價/貼文 2.59 | 送出評價 19 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/12 上午 06:07:47

還有一個多重繼承的經典範例請參考design pattern,
其中的Adapter Pattern有兩種變形,
在第一種變形中,
Adapter class就是多重繼承自Target class和Adaptee class,
但請注意,
對Target class是採public繼承,
而對Adaptee class是採private繼承 => 因為這是實作用的
(你也順便學到了其中一個漂亮的private繼承使用時機)

多重繼承只是手段,
懂得避開缺點, 善用它,
有時更能設計出更簡潔, 更犀利的介面.
作者 : visionhsiao(茶僮)
[ 貼文 20 | 人氣 395 | 評價 60 | 評價/貼文 3 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/8/13 下午 10:33:47

>我個人認為物件導向的繼承設計上是有缺陷的~
>繼承的目的無非是為了程式碼的重用~

同意

>但是在設計上個人認為實在是困難重重~
>原因是要設計一個好的基底類別相當不容易~

同意

>因為物件繼承的架構總是以一總集合的方式來描述~
43
>所以說我們如何在還沒有任何具動物特性的東西出現前就發明動物呢?
>這點讓我覺得繼承在設計上很困難(也許用起來容易)~

其實,在規劃分析階段就要發明出動物了,然後在實作出貓狗豬等

>至於多重繼承就是將許多不同特性的類別整合起來~
>例如某樣新的東西同時繼承了鞋子與電話~
>於是出現了可以打電話的鞋子~
>當你在球場上打球時鞋子響了~
>於是就可以把鞋子接起來(也許有點味道)~
>並和朋友討論晚上要去那吃飯~
>如此先進的鞋子去那找ㄚ~
>但是多重繼承在實做上有些不好的地方~
>像是名稱衝突(光這點就很嚴重了)~
>像我上面舉的例子其實還不太容易發生衝突~
>但是如果是某樣新的多功能鞋同時繼承了籃球鞋與慢跑鞋了話~
>事情就大條了~
>多功能鞋的鞋帶到底要用籃球鞋的好呢還是慢跑鞋~
>跑的時候到底是要慢跑鞋的輕盈呢還是籃球鞋的高保護性~
>於是就開始打架了~
>因為只要是繼承來的東西都會同時存在的~
>任何的特性都不會被埋沒~
>所以我覺得多重繼承很不好~
>因為往往繼承的東西都太具象(抽象的反意)了~
>總之,多重繼承是bug的泉源~
43

我覺得應該是沒有規劃好類別跟繼承的關係

以之前動物作說明好了
在國中時生物課提到自然街的分類模式
界-門-綱-目-科-屬-種
大家都知道貓跟狗都是同屬貓科動物嗎??
假設貓科是父類別,則犬屬跟貓屬就是繼承了貓科再加上其他特徵所產生的類別了
同樣犬屬跟貓屬再另外加上其他特徵,於是狗種狼種狐種就出現了,獅種虎種貓種也出現了

要使用多重繼承之前,繼承的類別及層級要規劃好,避免出現狼種繼承貓屬或虎種繼承犬屬就行了
作者 : murpphy(Killer)
[ 貼文 80 | 人氣 522 | 評價 440 | 評價/貼文 5.5 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/17 下午 02:07:25
>我個人認為物件導向的繼承設計上是有缺陷的~
>繼承的目的無非是為了程式碼的重用~

難以苟同。
想想看,如果MICROSOFT MFC沒有實作繼承,而用dll library完成這些功能(一樣是程式碼重用),那學習的人會多痛苦。這表示如果繼承鏈不夠漂亮,這個系統未來將難以維護。

>但是在設計上個人認為實在是困難重重~
>原因是要設計一個好的基底類別相當不容易~

難以苟同。
類別設計不好,通常是因為需求不明所導致;物件導向本就應該建立在完善的軟體開發工程上,否則用傳統的結構化程式設計可能還安全一點。



的確很多物件導向的書籍都將多重繼承視為洪水猛獸,但他們欲決對不會否定其價值。自認有本事就用吧,反正責認自負,但如果對OOA、OOD不是很有經驗者,切勿輕易嘗試
作者 : d8231657(denny)
[ 貼文 58 | 人氣 4556 | 評價 70 | 評價/貼文 1.21 | 送出評價 10 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/11/25 下午 02:34:15

>以之前動物作說明好了
>在國中時生物課提到自然街的分類模式
>界-門-綱-目-科-屬-種
>大家都知道貓跟狗都是同屬貓科動物嗎??
>假設貓科是父類別,則犬屬跟貓屬就是繼承了貓科再加上其他特徵所產生的類別了
>同樣犬屬跟貓屬再另外加上其他特徵,於是狗種狼種狐種就出現了,獅種虎種貓種也出現了
>
>要使用多重繼承之前,繼承的類別及層級要規劃好,避免出現狼種繼承貓屬或虎種繼承犬屬就行了
>
胡說八道,狗是動物界脊索動物門哺乳綱食肉目犬科犬屬犬種,別教壞小孩子
作者 : player(PLAYER) 貼文超過1000則人氣指數超過100000點
[ 貼文 1595 | 人氣 138661 | 評價 2840 | 評價/貼文 1.78 | 送出評價 104 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/12/16 下午 04:01:03
多重繼承
最怕物件迷宮吧
尤其是出現了交叉繼承的時候

至於
虛擬函式最好還是先放個預設值上去
即使只是個什麼都不做的空函式
也比函式定義成 = 0 好多了
至少衍生類別不必先把對應的函式補上

作者 : thinkeryzu(Thinker)
[ 貼文 8 | 人氣 2 | 評價 40 | 評價/貼文 5 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/1/9 下午 07:10:11

>>我個人認為物件導向的繼承設計上是有缺陷的~
>>繼承的目的無非是為了程式碼的重用~
>
>難以苟同。
>想想看,如果MICROSOFT MFC沒有實作繼承,而用dll library完成這些功能(一樣是程式碼重用),那學習的人會多痛苦。這表示如果繼承鏈不夠漂亮,這個系統未來將難以維護。
>
>>但是在設計上個人認為實在是困難重重~
>>原因是要設計一個好的基底類別相當不容易~
>
>難以苟同。
>類別設計不好,通常是因為需求不明所導致;物件導向本就應該建立在完善的軟體開發工程上,否則用傳統的結構化程式設計可能還安全一點。
>
我不覺的因為使用 OO, 所以需要更完善的軟體開發工程. 需求不明是所有軟體開發模式的共同問題. XP 讓我們認清一件事, 接受風險, 和風險共處. 風險包含需求不明, 這個風險一直是存在的. 我們應當認清, 並
接受這個事實. 學習和需求不明相處, 而非排除這個因素, 假設一個理想狀況.

另一方面, 我也不認同設計一個好的 base class 如此的困難, 比為一個 module 計設一組好的 interface
還困難. 困難的是改變思考的立場和角度, 尤其是習於結構化程式設計的人.

作者 : netsaver(Andrew)
[ 貼文 15 | 人氣 2286 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/4/29 下午 02:40:54
好處是,可以讓程式設計更具彈性.
壞處是,可以讓人寫出複雜難懂,甚至有問題的程式碼.

但是,「複雜難懂,甚至有問題的程式碼」並不是只有多重繼承才會產生.

我覺得,多重繼承是工具,如何正確地使用,是設計者的責任.就好像手排車與自排車,不會開手排車的人,當然覺得難開.雖然手排車較難操控,但卻可以做更多自排車做不到的事(如:甩尾,anyway).

個人想法,請多指教。
 板主 : Clark
 > 物件導向程式設計 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 物件導向程式設計 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
物件導向程式設計
1 Arthur 180 
2 藍色LED 150 
3 長長 100 
4 Linkin 100 
5 love seeker 100 
6 Raymond 90 
7 Nets 80 
8 nop 70 
9 Huah 70 
10 矇矇 60 
物件導向程式設計
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/
0.09375