【发布时间】:2013-06-25 16:16:04
【问题描述】:
假设我有一个简单的继承链,其中Employee 是抽象基类,Checkout 和Manager 在这个纯粹说明性的控制台应用程序中继承自它。现在我想要一个方法,它可以接收Manager 或Checkout 类型的对象,并根据员工在公司的职位返回整数数量的奖金。我对此有一些初步的想法,并且想知道如果这个控制台应用程序有朝一日成长为数据驱动的 Web 应用程序,每种方法的潜在长期缺陷或收益。
-
使用继承类通用的接口。 我的基类看起来像
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 类型的参数,并且在 Manager 类中我们必须测试是否员工is-a经理。
对于长期 Web 应用程序,1-2 是否同样具有可扩展性和可管理性?选项 3 真的像我说的那么糟糕吗?
【问题讨论】:
-
我认为exist方法(使用接口)比其他方法更好
-
哦,不,这越来越糟了。不要把你的逻辑散布出去,绝对不要用
Main把它放在你的静态类中。写一个静态方法很好,但是把它放在抽象的Employee类中——如果你必须有一个方法的话。
标签: c# visual-studio-2010