Чи потрібно написати інтерфейс API перед реалізацією?

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

І якщо це так, у випадку використання сторонніх бібліотек (тобто Lidgren), чи потрібно я також загортати їх в інтерфейси та розв’язувати їх через контейнери МОК, чи все в порядку їх піддавати інтерфейсам?

На жаль, ви виявите, що це часто зводиться до особистих уподобань.

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

1. Напишіть скелет програми як інтерфейси, абстрактні класи (на шпильках) та класи (також заглушені)
2. Напишіть свої тести на ці інтерфейси та заглушки (вони зараз не спрацюють)
3. Напишіть свої реалізації (ваші тести почнуть проходити, коли ви закінчите свою реалізацію)

Ви зосереджуєтесь на спробі написати більше "організованого" коду. Наступний TDD допоможе вам у цьому.

Деякі додаткові моменти:

• IoC контейнери зручні. Використовуйте їх та DI стільки, скільки зможете.
• Як обернути 3 - бібліотеки. Це послабить зв'язок між вашим кодом (кодом, яким ви керуєте) та кодом сторонньої сторони (кодом, яким ви не керуєте)

Так, вам слід кодувати інтерфейси, а не відомі реалізації, і так, ви повинні спочатку побудувати інтерфейси, а не виходити з власного коду.

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

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

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

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

Замість того, щоб по-рабськи просто програмувати інтерфейси, чому б не заглянути в тестові керовані розробки / дизайн (TDD)?

Багато людей вважають TDD як тестувальну практику, але насправді це підхід до дизайну, де ви дозволяєте тестам викрити те, як ваш код буде використовуватися за допомогою тестів (спочатку через одиничні тести, але можуть бути також через інтеграційні тести).

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

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

Що стосується використання сторонніх бібліотек, я б настійно рекомендував обгортати їх у власних абстракціях, де це доречно; і не дозволяйте клієнтам вашого API "знати" про них.

Щасти!

[редагувати: побачив відповідь мегапольоту - повністю згоден]

Я думаю, що це надмірно. Якщо користувача вашого API не потрібно змушувати реалізовувати / використовувати щось певним чином, то я б це не залишав. Інтерфейси - це договори, якщо мені це не потрібно, то навіщо мені його давати?

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

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

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

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