Подтвердить что ты не робот

Вывести абстрактный класс из не-абстрактного класса

Можно ли получить абстрактный класс из не-абстрактного класса или что-то не так с этим подходом?

Вот небольшой пример:

public class Task {
  // Some Members
}

public abstract class PeriodicalTask : Task {
  // Represents a base class for task that has to be done periodicaly.
  // Some additional Members
}

public class DailyTask : PeriodicalTask {
  // Represents a Task that has to be done daily.
  // Some additional Members
}

public class WeeklyTask : PeriodicalTask {
  // Represents a Task that has to be done weekly.
  // Some additional Members
}

В приведенном выше примере я не хочу создавать абстрактную задачу Task Task, потому что я хочу ее создать непосредственно. PeriodicalTask ​​должен наследовать функциональность от Task и добавлять некоторые дополнительные элементы, но я не хочу создавать его напрямую. Необходимо создать экземпляр только производного класса PeriodicalTask.

4b9b3361

Ответ 1

Я не вижу ничего плохого в этом подходе.

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

Пример реального мира:

Person - бетон (не абстрактный)
Sibling: Person - аннотация
Brother: Sibling - бетон
Sister: Sibling - бетон

Ответ 2

В этом нет ничего плохого.

Если вы посмотрите на большую иерархию, такую ​​как WinForms, вы найдете несколько слоев абстрактных типов.

Задачи MSBuild также являются хорошим (и более релевантным) примером.

Ответ 3

Такое происходит всегда: все абстрактные классы наследуют от System.Object, класс, который не является abstract сам по себе.

new System.Object() иногда полезен для блокировки, если у вас нет ничего вокруг, вы можете заблокировать его.

Ответ 4

Использование абстракции здесь не является правильным подходом, например, использовать защищенный или внутренний конструктор. Это предотвратит создание экземпляров PeriodicalTask ​​напрямую, но его производные классы все равно будут иметь к нему доступ.