OOD, наследование и супертип слоя

Question

У меня есть вопрос, касающийся хранения общего кода в базовом классе и вызова его производным классом, хотя метод триггера производного класса был отправлен из базового класса. Итак, base-> производный-> стек вызовов базового типа.

Это выглядит нормально или пахнет? Я пронумеровал шаги потока ...

public abstract class LayerSuperType
{
  public void DoSomething()  // 1) Initial call from client
  {
    ImplementThis(); // 2) Polymorphic dispatch
  }

  protected abstract void ImplementThis();

  protected void SomeCommonMethodToSaveOnDuplication(string key)  // 4)
  {
    Configuration config = GetConfiguration(key);
  }
}

public class DerivedOne : LayerSuperType
{
  protected virtual void ImplementThis() // 2)
  {
    SomeCommonMethodToSaveOnDuplication("whatever");  // 3) Call method in base
  }
}

public class DerivedTwo : LayerSuperType
{
  protected virtual void ImplementThis() // 2)
  {
    SomeCommonMethodToSaveOnDuplication("something else"); // 3) Call method in base
  }
}

Answer 1

Это выглядит абсолютно нормально.Прекрасный пример того, почему вы используете абстрактный класс поверх интерфейса.Это немного похоже на шаблон стратегии, и я использовал его довольно регулярно и успешно.

Убедитесь, что то, что делает класс, все еще имеет дело с одной «заботой», а только с одной задачей.Если ваш базовый класс имеет доступ к хранилищу, но объекты представляют документы, не помещайте функциональность в базовый класс, используйте отдельный шаблон / объект хранилища.

Answer 2

Выглядит как очень упрощенный Шаблонный шаблон , где ваши подклассы делают определенные вещи в нужных точках реализации вашего алгоритма, но весь поток направляется методом на Базовый класс. Вы также предоставили некоторые услуги своим подклассам в форме методов базового класса; это тоже нормально, пока ты хорош, пока SOLID идет.

Answer 3

Почему бы не public abstract void DoSomething() и вообще забыть о ImplementThis()?

Единственная причина, по которой я могу уйти ImplementThis(), заключается в том, что вы хотите поддерживать согласованный интерфейс с DoSomething(), который в дальнейшем позволит изменять сигнатуру ImplementThis() без серьезных изменений.для вызывающих абонентов.

Я согласен с тем, что вы должны поддерживать единую заботу об ответственности класса, но с точки зрения общего ООП это выглядит хорошо для меня.Я делал подобное во многих случаях.

Answer 4

Немного пахнет, что SomeCommonMethodToSaveOnDuplication вызывается двумя разными способами.Кажется, он делает две несвязанные вещи.Почему бы не иметь два метода?