創建新類型時如何處理多個對象類型

Question

被委託編寫一些資產跟蹤軟件... 想要嘗試以正確的方式執行此操作。所以我認爲很多資產都有共同的領域。例如，計算機具有手機也具有的型號和製造商。

我想存儲計算機，顯示器，手機等。所以我認爲可以使用抽象基類來考慮常見的東西。其他不相互關聯的屬性將存儲在實際的類本身中。

例如，

public abstract class Asset { 
private string manufacturer; 

    public string Manufacturer { get; set; } 
    //more common fields 
} 

    public class Computer : Asset { 
    private string OS; 
    public strin OS { get; set; } 
    //more fields pertinent to a PC, but inherit those public properties of Asset base 
    } 

    public class Phone : Asset { 
    //etc etc 
    } 

但我有2個顧慮：

1）如果我有一個Web表單，要求別人添加的資產，我想給他們說的一個單選框選擇他們正在創建的資產類型。東西的效果：

你在創建

[]計算機

[]電話

[]監測

[確定] [取消]

而且他們會選擇一個，但我不想結束這樣的代碼：

僞代碼：

select case(RadioButtonControl.Text) 
{ 
    case "Computer": Computer c = new Computer(args); 
        break; 
    case "Phone": Phone p = new Phone(args); 
       break; 
    .... 
} 

這可能會變得醜陋....

問題2）我想在一個數據庫表中該信息這種方式存儲與TYPEID場當插入到數據庫完成本值成爲該行的typeid（區分它是計算機，顯示器，電話等）。這個typeid字段是否應該作爲某種枚舉在基本抽象類中聲明？

謝謝

Answer 1

我的建議是完全避免這種通用設計。根本不要使用繼承。當不同類型的對象具有不同的行爲時，對象方向效果很好。對於資產跟蹤，沒有一個對象真的有任何行爲 - 你存儲的是相對「啞」的數據，它們都沒有（或者應該）真的做任何事情。

現在，你似乎正在接近這個作爲一個面向對象程序與數據庫作爲支持存儲（可以這麼說）。我會反過來：它是一個前端（或至少可能是）面向對象的數據庫。

然後，除非您在資產追蹤中有一些非常特殊和不尋常的需求，否則很有可能您不應該這樣做。市場上已經有幾十種完全合理的資產跟蹤軟件包。除非你的需求真的非常不尋常，否則重新發明這個特定的輪子不會有太大的成就。

編輯：我不打算建議在應用程序本身內使用OOP。恰恰相反，MVC（例如）工作得很好，我幾乎肯定會將它用於這類任務。

在哪裏我會避免OOP將在被存儲的數據的設計。在這裏，您從使用諸如OLE DB，ODBC或JDBC之類的基於SQL的數據庫之類的東西中獲益更多。

爲此，使用半標準組件幾乎可以自動爲您提供可伸縮性和增量備份等功能，並且很可能使將來的需求（例如與其他系統集成）相當容易，因爲您將擁有標準化的理解層訪問數據。編輯2：至於什麼時候使用（或不使用）繼承，一個提示（儘管我承認它不超過）是行爲，以及您是否真的考慮層次結構反映對您的計劃很重要的行爲。在某些情況下，您使用的數據在程序中相對「活躍」 - 即程序本身的行爲圍繞着數據的行爲。在這種情況下，它是有意義的（或者至少可以有意義）在數據和代碼之間具有相對緊密的關係。

然而，在其他情況下，代碼的行爲相對不受數據影響。我認爲資產追蹤就是這種情況。對於資產追蹤計劃來說，無論現在的物品是電話，收音機還是汽車，它都不會產生太大的影響（如果有的話）。有一些（通常更廣泛的）類別可能想要考慮 - 至少對於不少業務來說，重要的是資產是否被視爲「房地產」，「設備」，「辦公用品」等。這些分類導致了資產如何跟蹤，必須支付的稅款等方面的差異。

同時，屬於辦公用品（如回形針和訂書釘）的兩件物品沒有明顯不同的行爲 - 每種物品都有描述，成本，位置等等。根據您的嘗試當數量低於一定水平時，每個人可能都會觸發事件，讓別人知道是時候重新訂購了。

總結這種方式的一種方式可能是考慮程序是否可以合理地處理並非真正設計的數據。對於資產跟蹤，您幾乎不可能（或者想要）爲某人可能決定跟蹤的每種對象創建一個類。您需要從一開始就計劃它將用於您在原始設計中未明確說明的各種數據。很可能對於大多數項目，您需要設計自己的代碼，以便能夠傳遞數據，而不必知道（或關心）很多關於內容的大部分。

對代碼中的數據進行建模主要在何時/如果程序確實需要知道數據的確切屬性，並且在沒有它的情況下無法合理運行。