Ніколи не робіть публічних членів віртуальними / абстрактними - справді?

Ще в 2000-х моїй колезі сказали мені, що це зробити анти-зразком зробити публічні методи віртуальними чи абстрактними.

Наприклад, він вважав такий клас, як недостатньо розроблений:

public abstract class PublicAbstractOrVirtual
{
  public abstract void Method1(string argument);

  public virtual void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    // default implementation
  }
}

Він заявив, що

• розробник похідного класу, який реалізує Method1та переосмислює Method2, повинен повторити перевірку аргументів.
• якщо розробник базового класу вирішить додати щось навколо налаштованої частини Method1або Method2пізніше, він не може цього зробити.

Натомість мій колега запропонував такий підхід:

public abstract class ProtectedAbstractOrVirtual
{
  public void Method1(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method1Core(argument);
  }

  public void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method2Core(argument);
  }

  protected abstract void Method1Core(string argument);

  protected virtual void Method2Core(string argument)
  {
    // default implementation
  }
}

Він сказав мені, що публічні методи (або властивості) віртуальними чи абстрактними є такими ж поганими, як і оприлюднення полів. Вставляючи поля у властивості, можна перехопити будь-який доступ до цих полів пізніше, якщо потрібно. Це ж стосується публічних віртуальних / абстрактних членів: обведення їх так, як показано в ProtectedAbstractOrVirtualкласі, дозволяє розробнику базового класу перехоплювати будь-які виклики, що переходять до віртуальних / абстрактних методів.

Але я не розглядаю це як керівництво дизайном. Навіть Microsoft не дотримується цього: просто подивіться на Streamклас, щоб перевірити це.

Що ви думаєте про цю інструкцію? Це має сенс, чи ви вважаєте, що це надмірно ускладнює API?

Говорячи

що це анти-шаблон, щоб зробити публічні методи віртуальними або абстрактними через розробника похідного класу, який реалізує Method1 і замінює Method2, повинен повторити перевірку аргументів

це змішування причини та наслідку. Це робить припущення, що кожен перезавантажений метод вимагає неперенастроюваної перевірки аргументів. Але це зовсім навпаки:

Якщо ви хочете розробити метод таким чином, щоб він мав деякі фіксовані перевірки аргументів у всіх похідних класу (або - загальніше - налаштована та не налаштована частина), то має сенс зробити точку входу невіртуальною. , а натомість надайте віртуальний або абстрактний метод для налаштованої частини, яка викликається внутрішньо.

Але не багато прикладів , коли це має сенс мати публічний віртуальний метод, так як там немає фіксованого не налаштовувати частина: погляд на стандартні методи , такі як ToStringабо Equalsабо GetHashCode- б це поліпшити дизайн objectкласу , щоб вони не громадськості і віртуальний одночасно? Я не думаю, що так.

Або з точки зору власного коду: коли код у базовому класі остаточно і навмисно виглядає так

 public void Method1(string argument)
 {
    // nothing to validate here, all strings including null allowed
    this.Method1Core(argument);
 }

поділ між ними Method1і Method1Coreлише ускладнює речі без видимих ​​причин.

Робити це так, як пропонує ваш колега, забезпечує більшу гнучкість для виконавця базового класу. Але разом із цим також виникає більш висока складність, яка, як правило, не виправдана припущеними перевагами.

Зверніть увагу, що підвищена гнучкість для реалізатора базового класу відбувається за рахунок меншої гнучкості для переважаючої сторони. Вони отримують певну поведінку, про яку вони можуть не особливо піклуватися. До них речі тільки стали більш жорсткими. Це може бути виправдано і корисно, але все це залежить від сценарію.

Конвенція про іменування для реалізації цього (про що я знаю) полягає в тому, щоб зарезервувати гарне ім'я для загальнодоступного інтерфейсу та встановити ім'я внутрішнього методу на "Do".

Один корисний випадок, коли виконувана дія потребує певного налаштування та закриття. Як відкрити потік і закрити його після того, як буде зроблено переопределитель. Загалом, такий самий варіант ініціалізації та доопрацювання. Це дійсна модель, але використовувати її в усіх абстрактних та віртуальних сценаріях було б безглуздо.

У C ++ це називається невіртуальний шаблон інтерфейсу (NVI). (Колись його називали Метод шаблонів. Це було заплутано, але деякі старі статті мають цю термінологію.) NVI пропагує Герб Саттер, який писав про це принаймні кілька разів. Я думаю, що один із самих ранніх тут .

Якщо я пам'ятаю правильно, передумова полягає в тому, що похідний клас не повинен змінювати те, що робить базовий клас, а як це робить.

Наприклад, Shape може мати метод Move для переміщення фігури. Конкретні реалізації (наприклад, такі як Квадрат і Кола) не повинні безпосередньо змінювати Move, оскільки Shape визначає, що означає Moving (на концептуальному рівні). Квадрат може мати різницю деталей реалізації, ніж Коло, з точки зору того, як позиція представлена ​​внутрішньо, тому їм доведеться перекрити якийсь метод, щоб забезпечити функціональність Move.

У простих прикладах це часто зводиться до загальнодоступного Move, який просто делегує всю роботу приватному віртуальному ReallyDoTheMove, тому здається, що багато накладних витрат без жодної користі.

Але це листування один до одного не є вимогою. Наприклад, ви можете додати метод Animate до публічного API Shape, і він може реалізувати це, викликаючи ReallyDoTheMove у циклі. Ви отримуєте два API невіртуальних методів, які обидва покладаються на один приватний абстрактний метод. Ваші кола та квадрати не потребують додаткових робіт, а також не можуть переосмислювати анімацію .

Базовий клас визначає публічний інтерфейс, який використовують споживачі, і визначає інтерфейс примітивних операцій, необхідний для реалізації цих публічних методів. Похідні типи відповідальні за забезпечення реалізації цих примітивних операцій.

Я не знаю жодних відмінностей між C # і C ++, які змінили б цей аспект дизайну класу.