Інтерфейси
Важко зрозуміти призначення інструменту, який вирішує проблему, якої у вас ніколи не було. Я не розумів інтерфейси деякий час після початку програмування. Ми зрозуміли, що вони зробили, але я не знав, для чого ви хочете використовувати його.
Ось проблема - ви знаєте, що хочете зробити, але у вас є кілька способів зробити це, або ви можете змінити, як це зробити пізніше. Було б непогано, якби ви могли грати роль нерозумного менеджера - лайте кілька замовлень і отримуйте потрібні результати, не піклуючись про те, як це робиться.
Скажімо, у вас маленький маленький веб-сайт, і ви зберігаєте всю інформацію своїх користувачів у файлі csv. Не найскладніше рішення, але воно працює досить добре, щоб зберігати дані вашої мами. Пізніше ваш сайт знімається, і у вас є 10 000 користувачів. Можливо, настав час використовувати належну базу даних.
Якби ви спочатку були розумними, ви б бачили, що це наближається, і не дзвонили, щоб зберегти безпосередньо в csv. Замість цього ви б подумали, що для цього потрібно зробити, незалежно від того, як це було здійснено. Скажімо, store()
і retrieve()
. Ви робите Persister
інтерфейс з абстрактними методами store()
і retrieve()
і створити CsvPersister
підклас , який фактично реалізує ці методи.
Пізніше ви можете створити файл, DbPersister
який реалізує фактичне зберігання та отримання даних абсолютно інакше, ніж те, як це робив ваш клас csv.
Чудова річ, все, що вам потрібно зробити зараз, - це зміни
Persister* prst = new CsvPersister();
до
Persister* prst = new DbPersister();
і тоді ви закінчите. Ваші дзвінки prst.store()
та prst.retrieve()
все ще працюватимуть, вони просто розглядаються по-різному «поза кадром».
Тепер вам все одно довелося створювати резюме та db-реалізацію, тож ви ще не відчували розкоші бути шефом. Реальні переваги очевидні, коли ви використовуєте інтерфейси, які створив хтось інший. Якщо хтось ще був добрим, щоб створити його CsvPersister()
і DbPersister()
вже, тоді вам просто потрібно вибрати один і подзвонити необхідні методи. Якщо ви вирішили використовувати інший пізніше або в іншому проекті, ви вже знаєте, як він працює.
Я справді іржавий на моєму C ++, тому я буду просто використовувати кілька загальних прикладів програмування. Контейнери - прекрасний приклад того, як інтерфейси полегшують ваше життя.
Ви можете Array
, LinkedList
, BinaryTree
і т.д. все підкласи з Container
яких має такі методи , як insert()
, find()
, delete()
.
Тепер, додаючи щось до середини пов’язаного списку, вам навіть не потрібно знати, що таке зв'язаний список. Ви просто зателефонували, myLinkedList->insert(4)
і він магічно повторить список і вставить його туди. Навіть якщо ви знаєте, як працює зв'язаний список (який ви насправді повинні), вам не доведеться шукати його конкретні функції, тому що ви, мабуть, уже знаєте, що вони використовують, якщо використовувати інший Container
раніше.
Анотація заняття
Абстрактні класи досить схожі на інтерфейси (ну технічно інтерфейси - абстрактний клас, але тут я маю на увазі базові класи, які мають деякі свої методи.
Скажіть, що ви створюєте гру, і вам потрібно визначити, коли вороги знаходяться на відстані від удару від гравця. Ви можете створити базовий клас, Enemy
який має метод inRange()
. Хоча про ворогів багато речей, які відрізняються, метод, що використовується для перевірки їх дальності, є послідовним. Тому у вашому Enemy
класі буде встановлений чіткий метод перевірки дальності, але чисті віртуальні методи для інших речей, які не мають подібності серед типів ворога.
Приємно в цьому, якщо ви зіпсуєте код виявлення діапазону або хочете налаштувати його, вам потрібно змінити його лише в одному місці.
Звичайно, існує багато інших причин інтерфейсів та абстрактних базових класів, але це деякі причини, чому ви можете їх використовувати.
Однотонні
Я використовую їх час від часу, і я ніколи не спалювався ними. Це не означає, що вони не зіпсують моє життя в якийсь момент, грунтуючись на досвіді інших людей.
Ось хороша дискусія про глобальну державу з боку більш досвідчених і обережних людей:
Чому Глобальна держава така зла?