現在我應該使用抽象基類來達到這個目的嗎？

我只是最近纔開始專業開發。我在大學期間學習了OOP，但不覺得我真的曾經在真實世界中使用它。現在我應該使用抽象基類來達到這個目的嗎？

基本上，在試圖在組織內創建/操縱特定類型的文檔時，我爲它創建了一個類，並且認爲只要我們想要創建/操作該特定類型的文檔，就可以創建一個它的實例，並給它一定的信息，讓它自己照顧。我知道我們正在計劃與其他類型的文件（我想我應該注意到，當我說文件類型，我的意思是類似於「費用報告」或「庫存清單」，如我在）我認爲所有這些類型的文檔都會共享某些功能（例如，在Excel中使用共享字符串或定義的名稱），所以我創建了一個抽象的Document類，並且認爲每種類型我們想創建的文檔可以擴展這個類。

當然，我仍然只使用一種類型的文檔，所以雖然我對所有文檔可能都有的方法有了一個概念，但我仍然只有一個抽象類和一個擴展它，所以它似乎有點不必要。

我想我的問題是：
1）我應該甚至在這裏使用抽象類。像這似乎是適當使用一個或我完全錯過了這一點？
2）如果我應該使用一個，我應該早點使用它嗎？我的意思是，我是否應該等到實際上在我面前有幾個文檔，才能真正確定它們之間共享什麼樣的功能，而不是假設我現在知道即使我只有一個類實現它？

謝謝。

來源

2010-07-23 M_R_H

抽象類從您的描述中聽起來是正確的：對於所有派生類型（其中一些可能是派生類可能更改的「默認」行爲）都有某些屬性和行爲。然而，一些派生類可能會有其他的替代行爲。如果沒有「默認」行爲並且只有方法規範，那麼接口會更合適。

至於是否爲時過早：您有多確定您會絕對是需要多個派生類。在不存在任何疑問的情況下，我不打算設置抽象基類。這就是所謂的YAGNI（你並不需要它）;在最後一分鐘之前不要創建代碼，否則您可能永遠不需要它，並且您已經爲自己承擔了額外的潛在維護。

來源

2010-07-23 19:18:55

我將在這裏給出答案，以幫助我確認在理論上，抽象是正確的方法（如果我將有更多的派生類），但也強調良好的編碼實踐（YAGNI）。我也很欣賞jlafay對Adeel的迴應的評論，即儘早編寫一個基類會是有益的，說實話，我很確定它會有更多的派生類。儘管如此，即使作爲一名新開發人員，我也應該知道，在企業界，即使我「確定」，也需要更多，但這並不一定意味着它會以這種方式結束。 – 2010-07-23 19:36:06

由於抽象類的目的是提供派生類可以共享的基類的通用定義。所以在這裏使用是完美的。

來源

2010-07-23 19:16:25 Adeel

我認爲這也是最好的例子。我想補充一點，如果開發人員確信他們需要從基類派生出來，那麼儘早寫一個抽象基類會是有益的。 – jlafay 2010-07-23 19:23:20

應該抽象出來：是的。

對於你應該這麼早使用它。是的，這是一個簡單的1，2，3規則。如果你必須寫一些東西，好的。兩次，根據其大小考慮共同使用。三次絕對會讓它變得很普遍。

我非常喜歡把事物儘可能通用化。當我必須不止一次地寫同樣的東西時，我生氣了。

來源

2010-07-23 19:22:25 Jack

我建議定義一個抽象類和一個或多個接口可能會有幫助。除了處理對象創建的例程（使用抽象類）之外，通常使用接口類型的參數和變量。基本的文檔和接口可能支持一些基本功能，如GetPageCount，RenderToScreenBitmap，RenderToPrinter，RenderToHtml，GetVersionInfo等。從抽象文檔類繼承的文檔類可以使用默認邏輯來處理任何不需要更改的功能。但是，使用界面而不是基本類型，可以讓某人通過添加必要的界面功能來改造另一種文檔類型（可能會繼承完全不同的某種文檔類型）以便在系統上使用。

請注意，對於諸如打印和渲染之類的東西，使用某種適配器模式可能會很好，但這超出了原始問題的範圍。用於屏幕查看的渲染與用於打印的渲染不同（在屏幕上查看時可能沒有牢固的「頁面」細分），因此對這些功能使用不同的方法可能是明智的，但實現的細節需要一些小心思想。

來源

2010-07-23 20:31:51 supercat

現在我應該使用抽象基類來達到這個目的嗎？

回答

相關問題