Модульне програмування в Java ДЛЯ ANDROID

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

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

Розробник починає з створення класу транспортних засобів, в якому міститься вся транспортна логіка і вся логіка для конкретного типу двигуна, ось так:

Це спрощений код Він, можливо, і буде працювати, але в ньому перемішані не повязані один з одним типи реалізації (наприклад, всі типи двигунів) Тому код буде складно розширювати Розглянемо, наприклад, випадок, в якому потрібно змінити реалізацію і додати в неї новий тип двигуна (ядерний) Код для кожного різновиду автомобільного двигуна має необмежений доступ до коду будь-якого іншого двигуна Помилка в реалізації двигуна може спровокувати помилку в зовсім іншому двигуні Зміна одного двигуна може привести до несподіваних змін в іншому І, звичайно ж, машині, в якій немає електричного двигуна, доведеться проте тягнути з собою подання всіх існуючих в системі типів двигунів Розробники, яким в перспективі доведеться реалізувати для цієї програми монолітний двигун, повинні розуміти всі складні взаємодії, які можуть виникнути при зміні коду Деякі категорії просто непорівнянні

Як можна було б поліпшити цю реалізацію Очевидна ідея – використовувати підкласи Наприклад, ієрархію класів, представлену в наступному коді, можна застосувати для реалізації різних типів транспортних коштів, кожне з яких буде жорстко повязано з типом двигуна:

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

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

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

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

Джерело: Android Програмування на Java для нового покоління мобільних пристроїв

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*