Три об’єктно-орієнтованих принципи проектування, якими ви обов’язково повинні скористатися! навчитися програмувати
Заробіток:
- Що таке голлівудський принцип?
- Що означає інверсія залежності?
- Що розуміється під принципом найменшого знання?
- Що таке закон деметрів?
Ми вже говорили про те, чому дотримання певних правил може врятувати нас від набору блакитних очей.
З одного боку, ми працюємо не поодинці, особливо над великими проектами, і наші колеги також повинні вміти працювати з нашим кодом без нервового зриву і мати можливість використовувати його повторно.
Але, звичайно, ми також отримуємо від цього користь самі.
Бабусиний яблучний пиріг - найкращий!
То навіщо змінювати рецепт, коли ми можемо вирішити проблему перевіреним і, перш за все, відомим способом.
Тому в цій статті ми хочемо розглянути ще три об’єктно-орієнтованих принципи проектування.
Голлівудський принцип
Не дзвоніть нам, а ми вам!
Або німецькою мовою: ми зв’яжемося з вами!
Ось так агенти Голлівуду проводять відбору кандидатів.
Як тільки кандидат виявляється придатним, він повідомляє про це агента. Однак навпаки, кандидат не може отримати зв’язку з агентом.
Події - це об’єктно-орієнтована концепція, яка працює саме за цим принципом.
Наприклад, як працюють події в текстовому процесорі?
Текстовий процесор, такий як Word, складається з двох областей.
З одного боку, область, в якій ви редагуєте свій текстовий документ, а з іншого боку, меню, в якому ви можете вказати шрифт, розмір шрифту або колір тексту, наприклад.
Хто тут агент, а хто кандидат?
Замість кандидата та агента ми говоримо про абонента та спостерігача в програмуванні.
Безумовно, це не було б особливо ефективно, якщо область документа постійно запитує меню форматування, чи коригував користувач форматування тексту.
Отже, як тільки користувач переформатує текст через меню, запускається подія, про яку повідомляється область документа, а потім реагує відповідно.
Тому в цьому прикладі меню форматування виконує роль спостерігача (агента), а область документа - це той абонент, який чекає сповіщень із меню.
Голлівудський принцип має особливе значення у зв'язку з так званими рамками.
Фреймворки - це бібліотеки програм, які звільняють розробника від певних стандартних завдань.
Наприклад, існують такі фреймворки, як Java FX, яка бере на себе взаємодію з користувачем в графічному інтерфейсі для нас.
Наприклад, якщо користувач натискає кнопку, ми повідомляємо про цю дію через фреймворк і можемо відповідно реагувати.
Принцип інверсії залежності
Наступним принципом, який ми хочемо розглянути, є принцип інверсії залежності.
Цей принцип на перший план ставить абстракцію та незалежну реалізацію.
Ми маємо справу не з електрикою, а лише з вилкою та розеткою.
Для того, щоб мати можливість реалізувати цей принцип, ми використовуємо так званий шаблон проксі, який дозволяє використовувати метод незалежно від його конкретної реалізації.
Інструментом, який ми використовуємо для цього, є інтерфейси Java.
Операції CRUD бази даних
Відомим прикладом принципу інверсії залежностей є підключення до бази даних через JPA (Java Persistence Architecture).
JPA служить інтерфейсом до використовуваної системи баз даних.
У кожній базі даних нам потрібні так звані CRUD-операції створення, читання, оновлення та видалення, за допомогою яких ми можемо створювати, читати, змінювати та видаляти записи бази даних.
Однак реалізація цих операцій відрізняється між різними системами баз даних.
Наприклад, реалізація цих операцій у базі даних Oracle відрізняється від такої в базі даних MySql.
Без JPA нам доведеться писати окрему реалізацію CRUD для кожної системи баз даних.
Наприклад, ми б мали окремий метод збереження, такий як saveSQL, savePostgresSQL або saveOracle для кожної системи баз даних .
І розробник, який хоче використовувати операцію збереження, повинен би кожного разу перевіряти, яка система баз даних використовується, і, залежно від цього, викликати правильний метод CRUD.
Якщо хтось тоді повинен мати ідею змінити систему баз даних, необхідні відповідні коригування коду.
Завдяки інтерфейсу JPA ми цього позбавлені. Залежно від використовуваної системи баз даних, ми можемо динамічно стикувати відповідну реалізацію з проксі-сервером JPA (навіть під час роботи програми).
Потім розробник, який хоче використовувати операцію CRUD, може викликати інтерфейсні методи CRUD, такі як save, незалежно від базової реалізації.
Самі різні реалізації не залежать одна від одної.
Принцип найменшого знання!
Ми вже багато разів про це говорили. Програмісти ледачі і завжди шукають шляхи, як врятувати собі роботу.
Хороший спосіб зробити це - використовувати роботу, виконану іншими розробниками.
Однак це корисно лише в тому випадку, якщо час ознайомлення із закордонним програмним кодом є якомога коротшим.
І тут у справу входить так званий принцип найменшого знання, або німецькою - принцип малознання.
Цей принцип має особливе значення у зв'язку з розробкою API (інтерфейс програмування програм).
Ви точно це теж знаєте? Якщо у вас є питання. До кого ви звертаєтесь Хороший друг або незнайомець з пішохідної зони?
Напевно, ви віддаєте перевагу зв’язатися зі своїм другом. Або?
І саме на цій основі базується принцип найменшого знання, який також відомий під назвою Закон Деметри.
Закон Деметри рекомендує спочатку попросити друга і лише потім зв’язатися з незнайомцем, якщо наш приятель не може нам допомогти.
Хто друг, а хто чужий?
Напевно ви ніколи не пили пива з методом, класом чи атрибутом. Або? Тож як у наших програмах ми визначаємо, хто є другом, а хто незнайомцем?.
Оскільки Закон Демітера є об’єктно-орієнтованим принципом проектування, ми повинні визначити, які методи та атрибути об’єкта належать нашим друзям.
Логічно, що всі методи одного класу дружать між собою. Отже, взаємний виклик методів у тому самому класі дозволений Законом Демітера.
Хто ще є одним із наших друзів?
Подібним чином, ми посилаємось на всі об'єкти, які ми передаємо як параметри, коли викликаємо метод як наших друзів.
Крім того, усі об'єкти (та їх атрибути), які ми створюємо в одному класі, також належать до нашого кола друзів.
Індикатором того, що ви порушуєте закон Демітера, є те, що у ваших викликах методів є більше одного (.) Оператора.
Гаразд, давайте практикувати те, що ми дізналися, на прикладі.
Ми в бібліотеці.
Бібліотека складається з книжкових полиць.
Для відображення цього об’єктно-орієнтованого на Java нам потрібні два класи. Один клас для полиць і один клас для самої бібліотеки.
Полиці, очевидно, належать до бібліотеки. Тому полиці дружать з бібліотекою.
Кожна полиця містить кількість книг, яку вона містить як атрибут.
Отже, кількість атрибутів книг є другом класу Книжкова полиця, але не класу Бібліотека .
Бо, скажімо, ми хочемо з’ясувати кількість книг на десятій полиці бібліотеки. Як може виглядати відповідний виклик методу?
У нашому зверненні є два моменти. Очевидно, ми порушуємо тут Закон про деметри. Дійсно, атрибут “кількість книг” не є другом бібліотечного класу.
Як ми можемо зробити так, щоб дзвінок відповідав Закону про деметри?
Щоб обійти цю проблему, ми повинні додати метод до класу бібліотеки, який безпосередньо повертає кількість книг на полиці.
Наприклад, такий метод може виглядати так.
Оскільки полиці знаходяться в бібліотеці, атрибут police є другом бібліотечного класу. Тому Закон про деметри не порушується в рамках методу getAnzahlRegal.
Тепер ми отримуємо кількість книг на полиці 10 із наступним викликом методу.
Оскільки метод getAnzahlInRegal є другом бібліотечного класу, ми не порушили закон про деметри в цьому випадку.
Висновок: У цій статті ви дізналися про ще три об’єктно-орієнтованих принципи проектування. Голлівудський принцип є основою для так званих рамок, які позбавляють нас від багатьох повторюваних і часто нудних рутинних завдань на практиці.
Інверсія залежностей дозволяє нам працювати з API (Інтерфейси програмування програм), в яких вона відокремлює визначення та реалізацію функції.
Основна проблема всіх принципів проектування, але особливо з принципом найменших знань, простіше зробити ваш код багаторазовим, легшим для розуміння та більш зручним для обслуговування.
Вам сподобалась стаття? Тоді негайно слідкуйте за нами у Facebook!
Кім Пітер
Привіт, мене звуть Кім, і я хочу стати чудовим програмістом. Ви берете участь?