2010-03-01 85 views
3

當創建一個C++繼承結構,則必須定義成員函數在多個地方完全一樣:C++:在繼承避免雙重維護層次結構

如果B是一個抽象基類,和d,E,和F所有從B繼承,你可能會有這樣的:

class B 
{ 
    virtual func A(... params) = 0; 
}; 

class D : public B 
{ 
    func A(... params); 
}; 

/* ... etc... similar implementations for E and F */ 

所以,這裏顯然有一些重複。如果B的接口很大,那麼如果接口需要更改,可能需要更改很多地方。

的同事,提出了一些權謀與嵌入式狡猾創建的#includes,鼻翼:

class D: public B 
{ 
    #include "B_Interface.h" // B_Interface.h is a specially crafted .h file 
} 

這似乎有點缺憾?是嗎?有沒有更好的解決方案來避免雙重維護?

另外,也許這裏的解決方案是真正更好的工具來支持語言,如Visual Assist X?

編輯:假設派生類必須具有唯一的實現。

+0

Boost庫實際上在某些部分做到了這一點,雖然不是用於繼承,只是爲了重用代碼。 – 2010-03-01 21:09:48

+0

爲什麼不使用宏而不是include?重點在於性能明智的'#include'意味着當宏已經在符號表中時查找文件。 – 2010-03-02 08:23:10

回答

12

實際上,更改界面最大的問題通常是使用的所有代碼,而不是實現它的代碼。如果實施者很容易改變它,它可能會讓用戶的生活更加艱難。

+3

同意 - 恕我直言和接口應該儘可能少地改變,所以如果這是一種痛苦,這是一件好事! – 2010-03-01 21:07:04

1

如果你必須反覆實施一些默認行爲,那麼他們應該只是虛擬的,而不是純虛擬的。

+0

在我的特殊情況下,每個派生類都有不同的實現。 – 2010-03-01 21:01:43

1

除了使用預處理器爲它不應該被用來我會盡我的編輯的另一種方式的(或IDE,如果這是你喜歡什麼)

4

,它是痛苦的改變廣泛使用的界面是不是一個錯誤;這是一個功能。

4

此外,也許這裏的解決方案是真正更好的工具來支持語言,如Visual Assist X?

沒錯。更改方法簽名是重構工具的一個key feature

+1

我第二個建議。如果你不得不重構C++代碼,我發現VAX非常好。 (我發現它也很好,其他許多原因也是如此。) – sbi 2010-03-02 10:46:17