Коли використовувати абстрактні класи замість інтерфейсів із методами розширення в C #?

"Абстрактний клас" та "інтерфейс" є подібними поняттями, причому інтерфейс є більш абстрактним з двох. Одним з відмінних факторів є те, що абстрактні класи забезпечують реалізацію методів для похідних класів, коли це необхідно. Однак у C # цей диференціюючий коефіцієнт був зменшений нещодавним введенням методів розширення, які дозволяють забезпечити реалізацію методів інтерфейсу. Ще один диференціюючий фактор полягає в тому, що клас може успадковувати лише один абстрактний клас (тобто багаторазового успадкування немає), але він може реалізовувати декілька інтерфейсів. Це робить інтерфейси менш обмежуючими та більш гнучкими. Отже, на C #, коли ми повинні використовувати абстрактні класи замість інтерфейсів із методами розширення?

Помітним прикладом моделі методу інтерфейсу + розширення є LINQ, де функціональність запитів надається для будь-якого типу, що реалізується IEnumerableза допомогою безлічі методів розширення.

Коли вам потрібна частина класу, яку потрібно реалізувати. Найкращим прикладом, який я використав, є шаблон шаблону методу .

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

Таким чином, ви можете визначити кроки, які будуть зроблені, коли Do () викликається, не знаючи специфіки того, як вони будуть реалізовані. Класи виведення повинні реалізувати абстрактні методи, але не метод Do ().

Методи розширень не обов'язково задовольняють частину рівняння "повинна бути частиною класу". Крім того, iirc, способи розширення не можуть (схоже, бути) загальнодоступними.

редагувати

Питання цікавіше, ніж я спочатку давав кредит. Після подальшого вивчення, Джон Скіт відповів на подібне запитання щодо SO на користь використання інтерфейсів + методів розширення. Також потенційним недоліком є використання відображення проти ієрархії об'єктів, розробленої таким чином.

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

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

Це все про те, що ви хочете моделювати:

Абстрактні заняття працюють у спадок . Будучи тільки спеціальні базові класи, вони моделюють деякі є- -relationship.

Наприклад, собака - тварина, таким чином, ми маємо

class Dog : Animal { ... }

Оскільки не має сенсу насправді створювати загальну тварину (як це виглядатиме?), Ми робимо цей Animalбазовий клас abstract- але це все ще базовий клас. А Dogклас не має сенсу, не будучи ані Animal.

Інтерфейси з іншого боку - це інша історія. Вони не використовують успадкування, але надають поліморфізм (який може бути реалізований і з успадкуванням). Вони не моделюють є- відносини, але більше він підтримує .

Візьмемо, наприклад, IComparable- об'єкт, який підтримує порівняння з іншим .

Функціональність класу не залежить від інтерфейсів, які він реалізує, інтерфейс просто забезпечує загальний спосіб доступу до функціоналу. Ми все-таки могли б Disposeзробити це Graphicsчи FileStreamбез того, щоб їх реалізувати IDisposable. Інтерфейс просто відноситься методи разом.

В принципі, можна додавати та видаляти інтерфейси так само, як розширення, не змінюючи поведінку класу, просто збагачуючи доступ до нього. Ви не можете хоч забрати базовий клас, оскільки об'єкт став би безглуздим!

Я тільки зрозумів, що не використовував абстрактні класи (принаймні не створені) роками.

Абстрактний клас є дещо дивним звіром між інтерфейсом та реалізацією. В абстрактних заняттях є щось, що засмучує моє павуче почуття. Я заперечую, не слід «піддавати» реалізації інтерфейсу жодним чином (або робити будь-які зв’язки).

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

Я б пішов на інтерфейси.

ІМХО, я думаю, що тут відбувається змішування понять.

Класи використовують певний тип успадкування, тоді як інтерфейси використовують інший тип успадкування.

Обидва види успадкування важливі і корисні, і кожен з них має свої плюси і мінуси.

Почнемо з початку.

Історія з інтерфейсами починається довгий час назад із C ++. У середині 1980-х, коли розроблявся C ++, ідея інтерфейсів як іншого типу ще не була реалізована (це прийшло б вчасно).

C ++ мав лише один вид успадкування, тип успадкування, який використовуються класами, іменований успадкуванням реалізації.

Щоб мати змогу застосувати рекомендацію GoF Book: "Програмувати для інтерфейсу, а не для реалізації", C ++ підтримує абстрактні класи та багатонаступне успадкування, щоб мати можливість робити те, що інтерфейси в C # здатні (і корисні!) Робити .

C # вводить новий тип типу, інтерфейси та новий вид успадкування, успадкування інтерфейсу, щоб запропонувати принаймні два різні способи підтримки "Програмувати для інтерфейсу, а не для реалізації", з одним важливим застереженням: лише C # підтримує множинне успадкування з успадкуванням інтерфейсу (а не з успадкуванням реалізації).

Отже, архітектурні причини інтерфейсів у C # - це рекомендація GoF.

Я сподіваюся, що це може допомогти.

З повагою, Гастоне

Застосування методів розширення до інтерфейсу корисно для застосування загальної поведінки в класах, які можуть мати спільний інтерфейс. Такі класи вже можуть існувати і бути закритими для розширень за допомогою інших засобів.

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

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

Я думаю, що в C # множинне успадкування не підтримується, і тому концепція інтерфейсу введена в C #.

У випадку абстрактних класів також не підтримується багатократне успадкування. Тому легко зважитися на використання більш абстрактних класів або інтерфейсів.

Я в процесі впровадження абстрактного класу у своєму проекті просто тому, що C # не підтримує операторів (неявні перетворення, в моєму випадку) на інтерфейсах.