假設我有一個簡單的繼承鏈,其中Employee
是抽象基類,Checkout
和Manager
在此純粹說明性的控制檯應用程序中繼承。現在我想擁有一個方法,它將接受Manager
或Checkout
類型的對象,並根據員工公司中的職位返回一個整數獎金。我對此有一些初步想法,並希望瞭解每種方法可能帶來的潛在長期不足或收益,如果這款控制檯應用程序有一天會成長爲數據驅動的Web應用程序。程序類中的抽象方法vs靜態方法
使用通用於繼承類的接口。 我的基類,看起來像
abstract class Employee { public int EmployeeId { get; set; } public string FirstName { get; set; } public string LastName { get; set; } }
和我的派生類實現設計爲可以打印員工信息稱爲
IPrintable
和只有一個方法,這樣做的控制檯界面。雖然這個界面與獎金沒有任何關係,但是我在課堂上用我的Main
方法嘲笑了以下內容,程序運行良好。static int GiveBonusesViaInterface(IPrintable i) { if (i is Checkout) return 1000; else return 2000; }
在我看來,如果我想使用的功能,這也許我應該再拍一個特定於給加薪,而不是騎一個已經實現的接口上的燕尾服(但這是另一天另一個問題)。
使用在基類中的靜態方法像
public static int GiveBonus(Employee e) { if (e is Manager) return 2000; else return 1000; }
請在抽象基類中的抽象方法和中堂派生類實現,因爲他們認爲合適的
abstract class Employee //fields and constructors { public abstract int GiveBonusesViaAbstractMethod(Employee e); }
這對我來說似乎是最糟糕的想法,因爲在每個派生類中必須有一個方法,這個方法需要參數IPrintable
或Employee
類型和經理類中,我們必須測試員工is-a
經理。
對於長期的Web應用程序,1-2是否具有可擴展性和可管理性?選項3真的和我一樣糟糕嗎?
我認爲存在的方法(使用接口)比其他 – 2013-06-25 16:21:32
好哦,不,這會變得更糟。不要傳播你的邏輯,絕對不要用'Main'把它放到你的靜態類中。編寫一個靜態方法很好,但把它放在抽象的'Employee'類中 - 如果你必須有一個方法。 –