Абстрактный метод против статического метода в классе программы

Question

Скажем, у меня есть простая цепочка наследования, где Employee - это абстрактный базовый класс, а Checkout и Manager наследуют его в этом чисто иллюстративном консольном приложении. Теперь я хочу иметь метод, который будет принимать объект типа Manager или Checkout и вернуть целочисленную сумму бонуса в зависимости от позиции в компании сотрудника. У меня были некоторые первоначальные мысли по этому поводу, и я хотел бы знать потенциальные долгосрочные дефициты или выгоды от каждого подхода, если это консольное приложение должно было в один прекрасный день стать веб-приложением, управляемым данными.

1. Используйте интерфейс, общий для унаследованных классов. Мой базовый класс выглядит

   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; 
   
   
        } 
   

   Мне кажется, что если бы я хотел использовать интерфейс для этого я, вероятно, следует сделать еще один специфический для предоставления прибавки вместо верхом на фалды на уже реализованный интерфейс (но это уже другой вопрос, на другой день).

2. Используйте статический метод в базовом классе как

   public static int GiveBonus(Employee e) 
        { 
         if (e is Manager) 
          return 2000; 
         else 
          return 1000; 
        } 
   

3. Сделать абстрактный метод в абстрактном базовом классе и неф производные классы реализуют, как они считают нужным

   abstract class Employee 
   //fields and constructors 
   { 
   public abstract int GiveBonusesViaAbstractMethod(Employee e); 
   } 
   

Мне кажется, это наихудшая идея, потому что в каждом производном классе должен быть метод, который принимает параметр IPrintable или Employee и в классе менеджера мы должны были бы проверить, есть ли у сотрудника is-a Manager.

Являются ли 1-2 одинаково масштабируемыми и управляемыми для долгосрочного веб-приложения? Действительно ли вариант 3 так же плох, как я это сделал?

Answer 1

Я думаю, что вы на самом деле уже ответили на свой вопрос.

мои производные классы реализуют интерфейс, предназначенный для печати информации о сотрудниках на консоли с именем IPrintable и только один способ для этого. Хотя этот интерфейс не имеет ничего общего с предоставлением бонусов

[курсив мой]

У вас уже есть интерфейс для этого. Это называется Employee. Идиоматический способ сделать это - реализовать виртуальный метод в вашем абстрактном классе и при необходимости переопределить. Более идиоматический подход C# заключается в том, чтобы написать свойство и переопределить его.Например:

abstract class Employee { 
    public virtual int GetBonus() 
    { 
    return this.Bonus; 
    } 

    public virtual int Bonus { get; set; } 
} 

class Manager : Employee { 
    public override int Bonus 
    { 
    get { return 2000; } 
    } 
} 

class Checkout : Employee { 
    public override int Bonus 
    { 
    get { return 1000; } 
    } 
} 

Answer 2

Вы упускаете традиционный OO способ сделать это:

abstract class Employee { 
    public int EmployeeId { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public abstract int GetBonusAmount(); 
} 

class Manager : Employee { 
    public override int GetBonusAmount() { return 2000; } 
} 

class Checkout : Employee { 
    public override int GetBonusAmount() { return 1000; } 
} 

Console.WriteLine(someEmployee.GetBonusAmount()); 

Answer 3

Внедрите метод GetBonus() в обоих подклассах. Вам следует избегать выполнения «экземпляра» проверок вообще.

Answer 4

Я думаю, абстрактные работы хорошо:

abstract class Employee 
{ 
    public int EmployeeId { get; set; } 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public abstract int GetVariableBonus(); 
} 

class Manager { 
    public int GetVariableBonus(){ 
     return 2000; 
    } 
} 

class Employee{ 
    public int GetVariableBonus(){ 
     return 1000; 
    } 
} 

Это то, что вам нужно?