У мене є кілька Processorкласів, які виконуватимуть дві дуже різні речі, але їх викликають із загального коду (ситуація "інверсія контролю").
Мені цікаво, з яких міркувань щодо дизайну я маю бути підозрілим (або пізнаючим для вас, користувачі США), приймаючи рішення про те, чи всі вони повинні успадкувати BaseProcessorабо реалізувати IProcessorяк інтерфейс.
Відповіді:
Як правило, правило звучить приблизно так:
Щоб дещо конкретніше сказати, давайте розглянемо приклад. System.Drawing.BitmapКлас є-ан зображень (і як такий, він успадковує від Imageкласу), але вона також може робити- утилізації, тому він реалізує IDisposableінтерфейс. Він також може виконувати серіалізацію, тому реалізується з ISerializableінтерфейсу.
Але більш практично, інтерфейси часто використовуються для імітації множинного успадкування в C #. Якщо ваш Processorклас повинен успадкувати щось на зразок System.ComponentModel.Component, то вам залишається лише вибір, як реалізувати IProcessorінтерфейс.
Справа в тому, що як інтерфейси, так і абстрактний базовий клас надають контракт, який вказує, що може робити конкретний клас. Поширений міф, що для оголошення цього контракту необхідні інтерфейси, але це не правильно. На мою думку, найбільшою перевагою є те, що абстрактні базові класи дозволяють вам надавати функціональність за замовчуванням для підкласів. Але якщо немає функціоналу за замовчуванням, який має сенс, ніщо не заважає вам позначати сам метод якabstract , що вимагає, щоб похідні класи реалізовували його самі, як якщо б вони реалізовували інтерфейс.
Щоб отримати відповіді на подібні запитання, я часто звертаюся до Керівних принципів проектування .NET Framework , де сказано про вибір між класами та інтерфейсами:
Загалом класи є найкращою конструкцією для викриття абстракцій.
Основним недоліком інтерфейсів є те, що вони набагато менш гнучкі, ніж класи, коли йдеться про можливість еволюції API. Після того, як ви надіслали інтерфейс, набір його членів закріплюється назавжди. Будь-які доповнення до інтерфейсу порушують існуючі типи, що реалізують інтерфейс.
Клас пропонує набагато більшу гнучкість. Ви можете додавати учасників до класів, які ви вже відправили. Поки метод не є абстрактним (тобто, поки ви надаєте реалізацію методу за замовчуванням), будь-які існуючі похідні класи продовжують функціонувати без змін.
[. . . ]
Одним з найпоширеніших аргументів на користь інтерфейсів є те, що вони дозволяють відокремлювати контракт від реалізації. Однак аргумент неправильно передбачає, що ви не можете відокремити контракти від реалізації за допомогою класів. Абстрактні класи, що знаходяться в окремій збірці від їх конкретних реалізацій, є чудовим способом досягнення такого розділення.
Їх загальні рекомендації такі:
Кріс Андерсон висловлює особливу згоду з цим останнім принципом, аргументуючи, що:
Абстрактні типи роблять версію набагато кращою і дозволяють розширюватися в майбутньому, але вони також спалюють ваш єдиний базовий тип. Інтерфейси доречні, коли ви дійсно визначаєте контракт між двома об'єктами, який інваріантний з часом. Абстрактні базові типи краще визначати загальну основу для сімейства типів.
Річард,
Чому ВИБІР між ними? Я мав би інтерфейс IP-процесора як опублікований тип (для використання в іншому місці в системі); і якщо трапляється так, що ваші різні СУЧАСНІ реалізації IProcessor мають спільну поведінку, то абстрактний клас BaseProcessor буде справді хорошим місцем для реалізації цієї загальної поведінки.
Таким чином, якщо вам потрібен IProcessor в майбутньому, який НЕ був для послуг BaseProcessor, він НЕ МОЖЕ його мати (і, можливо, приховати) ... але ті, хто хоче, можуть його мати ... у дубльованому коді / поняттях.
Просто моя скромна ДУМКА.
Ура. Кіт.
Інтерфейси є "контрактом", вони забезпечують реалізацію класом бажаного набору членів - властивостей, методів та подій -.
Базові класи (конкретні чи абстрактні, не має значення) є архетипом якоїсь сутності. Ось ці сутності представляють спільне в якомусь фактичному фізичному чи концептуальному.
Коли використовувати інтерфейси?
Кожного разу, коли якомусь типу потрібно заявити, що принаймні має деякі особливості поведінки та властивості, про які споживач повинен дбати, і використовувати їх для виконання якогось завдання.
Коли використовувати базові класи (конкретні та / або абстрактні)
Всякий раз, коли група сутностей має однаковий архетип, тобто B успадковує A, оскільки B є A з різницями, але B можна ідентифікувати як A.
Приклади:
Поговоримо про таблиці.
Ми приймаємо таблиці, що підлягають переробці => Це повинно бути визначено за допомогою інтерфейсу типу "IRecyclableTable", що гарантує, що всі таблиці, що підлягають переробці, матимуть метод "Recycle" .
Ми хочемо таблиці робочого столу => Це повинно бути визначено з успадкуванням. "Настільний стіл" - це "стіл". Усі таблиці мають загальні властивості та поведінку, а настільні матимуть однакові, додаючи такі речі, які змушують таблицю робочого столу відрізнятися від інших типів таблиць.
Я міг би говорити про асоціації, значення обох випадків у графіку об’єктів, але, на мій погляд, якщо мені потрібно навести аргументи з концептуальної точки зору, я точно відповів би цією аргументацією.
IRecyclableінтерфейс, оскільки здається ймовірним, що кілька непов'язаних об'єктів повинні бути перероблені (тобто інші класи, які не представляють таблиці). І тоді я все одно мав би реалізовувати всі таблиці з Tableкласу, включаючи DesktopTableі PicnicTableта FoldingTable.
Я не дуже добре розбираюсь у виборі дизайну, але якщо запитати, я віддаю перевагу впровадженню інтерфейсу iProcessor, якщо для розширення є лише члени. Якщо є інші функції, які не потрібно розширювати, кращий варіант успадкування від базового процесора.
Окрім чистоти дизайну, ви можете успадкувати лише один раз, тому, якщо вам потрібно успадкувати якийсь фреймворк-клас, питання спірне.
Якщо у вас є вибір, прагматично ви можете вибрати варіант, який заощаджує найбільше набору тексту. Це, як правило, вибір пуристів.
РЕДАГУВАТИ:
Якщо базовий клас матиме певну реалізацію, це може бути корисним, якщо він є суто абстрактним, тоді це також може бути інтерфейсом.
Враховуючи, що принципи SOLID пропонують більше ремонтопридатності та розширюваності вашого проекту, я віддаю перевагу інтерфейсам, а не успадкуванню.
Крім того, якщо вам потрібно додати "додаткову функціональність" до вашого інтерфейсу, найкращим варіантом є створення нового інтерфейсу, дотримуючись I в SOLID, що є принципом сегрегації інтерфейсу.
Якщо все, що ви оберете, не має значення, завжди вибирайте Interface. Це забезпечує більшу гнучкість. Це може захистити вас від майбутніх змін (якщо вам потрібно щось змінити в базовому класі, це може вплинути на успадковані класи). Це також дозволяє краще інкапсулювати деталі. Якщо ви використовуєте інверсію контролю інжекції залежності, вони, як правило, віддають перевагу інтерфейсу.
Або якщо уникнення спадщини неможливо, можливо, хороша ідея використовувати їх обох разом. Створіть абстрактний базовий клас, який реалізує інтерфейс. У вашому випадку ProcessorBase реалізує IP-процесор.
Подібно до ControllerBase та IController в ASP.NET Mvc.