Как Реализовать Базовый класс с Методом и все же вынудить Производный класс Переопределить его?
Шепелявость Emacs только имеет динамический обзор. Существует lexical-let макрос, который приближает лексический обзор посредством довольно ужасного взлома.
3 ответа
Ваш подход по существу правильный путь ...
Изменить:
Ваша «спецификация»:
- Поведение по умолчанию
- Требуется переопределение
Теперь, поскольку вы, кажется, хотите, чтобы "поведение по умолчанию" всегда выполнялось, вам потребуется
public string ToString()
{
// placeholder for some default behaviour
string result = doToString();
// placeholder for some more default behaviour
return result;
}
protected abstract string doToString();
Это работает, только если вы знаете, что делает базовый класс в целом, и хотите предоставить реализацию для doToString () в производном классе. Это известно как шаблон проектирования Template Method .
Однако, если вы ищете способ потребовать от разработчика производного класса для вызова base.ToString. () в его реализации ToString () , то нет возможности сделать это. Разрешив переопределение, вы даете производному классу контроль над его реализацией.
Вы можете задокументировать свою рекомендацию всегда вызывать base.ToString () , но не более того.
Использование интерфейса определяет публичный контракт для вашего класса. Это не дает вам каких-либо дополнительных преимуществ по сравнению с шаблоном шаблонного метода, поскольку вам все равно нужно унаследовать от базового класса для получения реализации «по умолчанию».
Есть ли у вас какие-либо подробности о том, что вы пытаетесь предоставить в своей базовый класс в качестве «поведения по умолчанию»? Может быть, это поможет прийти к лучшему решению. Если посмотреть на упомянутый вопрос, это, по сути, тот же подход.
Использование интерфейса определяет публичный контракт для вашего класса. Это не дает вам каких-либо дополнительных преимуществ по сравнению с шаблоном шаблонного метода, так как вам все еще нужно унаследовать от базового класса для получения реализации «по умолчанию».
Есть ли у вас какие-либо подробности о том, что вы пытаетесь предоставить в своей базовый класс в качестве «поведения по умолчанию»? Может быть, это поможет прийти к лучшему решению. Если посмотреть на упомянутый вопрос, это, по сути, тот же подход.
Использование интерфейса определяет публичный контракт для вашего класса. Это не дает вам каких-либо дополнительных преимуществ по сравнению с шаблоном шаблонного метода, поскольку вам все равно нужно унаследовать от базового класса для получения реализации «по умолчанию».
Есть ли у вас какие-либо подробности о том, что вы пытаетесь предоставить в своей базовый класс в качестве «поведения по умолчанию»? Может быть, это поможет прийти к лучшему решению. Если посмотреть на упомянутый вопрос, это, по сути, тот же подход.
? Может быть, это поможет прийти к лучшему решению. Если посмотреть на упомянутый вопрос, это, по сути, тот же подход. ? Может быть, это поможет прийти к лучшему решению. Если посмотреть на упомянутый вопрос, это, по сути, тот же подход.Нет, включить текущий виртуальный функцию в абстрактную функцию. Единственный способ добиться этого - создать другую абстрактную функцию, как вы предложили. Возможно, это более подходящий подход (и я согласен с этим).
Я только что узнал, что делать, чтобы добиться именно того поведения, которое я хотел:
public abstract class AAA
{
protected abstract string ToStringSpecific();
protected string ToString()
{
// Base Stuff
...
// Use this.ToStringSpecific();
}
}
public class BBB : AAA
{
protected override string ToStringSpecific()
{
// Specific Stuff
}
}