Google Guice Framework для розробника введення залежностей

Дослідження в 2336843 Продукти

Google Earth і Maps - це приклади інноваційного духу пошукового механізму. Інші проекти зарекомендували себе у власній розробці Google. Молодим членом цієї родини є фреймворк з відкритим кодом Guice, худа альтернатива Spring.

Google Guice, фреймворк із відкритим кодом для інжекції залежностей (DI), був створений під час розширення програми для реклами в Інтернеті AdWords і мав на меті вирішити проблеми з масштабуванням команд, які виникають у проектах із декількома сотнями розробників. Незважаючи на розпізнані фреймворки DI, такі як популярний Spring [1], Google хотів використати свій власний, особливо полегшений варіант для внутрішньої розробки програмного забезпечення (див. "Свободні відносини").

Загальні відомості та анотації з Java 5 є важливою частиною основи [2]. Крім того, Guice підтримує власні сфери (див. Глосарій), аспектно-орієнтоване програмування (AOP) та інтеграцію Spring. Можливість введення статичних атрибутів, а також управління циркулярними посиланнями доповнюють картину.

Планувальник отримує доступ до певних класів HotelBooking та MockBooking через інтерфейс бронювання (рис. 1).

Прикладом цього є програма планування відпусток, яка бронює готелі (рис. 1). Об'єкт планувальника (абонент) звертається до бронювання інтерфейсу, за яким приховані конкретні реалізації (цільові об'єкти). Щоб не потрібно постійно запитувати реальну цільову систему під час розробки, тут використовується так званий фіктивний об'єкт (фіктивний). Розробник повинен мати можливість легко перейти до продуктивної роботи.

Фреймворк повинен виглядати особливо худим і суттєво зменшувати "шаблонний код". Замість важкої роботи розробник повинен зайнятися найнеобхіднішим. З цією метою Guice концентрується виключно на високопродуктивній реалізації DI і відповідно зменшився як з точки зору розміру файлів JAR, так і споживання пам'яті. Guice не управляє залежностями в центральних файлах XML, а зберігає їх у коді Java.

вирішувати конфлікти

Вирішувати конфлікти з Java

Досвід показав, що розвиток не масштабується, якщо занадто багато учасників змагаються за доступ до основних компонентів. Потворні конфлікти неминучі при роботі зі спільними файлами XML. Редагування файлів Java також простіше і менш схильне до помилок, ніж редагування великих файлів XML. Це робить рефакторинг помітно простішим та краще підтримується інструментами. Guice вже пройшов практичне випробування в AdWords. Він також є частиною відомого веб-середовища Struts 2, в якому він є центральним елементом архітектури плагіна. Guice може надавати корисні послуги у всіх додатках Java. Великі проекти, зокрема ті, що зосереджені виключно на ефективній ін’єкції залежності. Тут Guice може відіграти свої сильні сторони, такі як стрункість та безпровідне підключення XML (див. "Добре підключений").

Програма для планування відпусток знову використовується як приклад. Завдання Guice - призначити планувальнику бажаний конкретний об'єкт бронювання, до якого він може отримати доступ через інтерфейс. У розглянутому випадку це повинен бути об’єкт MockBooking. Для цього потрібно з’ясувати, що куди вводять. На першу частину запитання відповідає так званий модуль із "підшивкою", який разом призначає інтерфейс реалізації. Наступний фрагмент коду формує такий модуль і використовує метод bind () для прив'язки інтерфейсу Booking до конкретного класу MockBooking .

Анотація @Inject в об'єкті планувальника піклується про те, "де":

Анотація @Inject вказує на те, що об’єкт Booking потрібно вводити за допомогою конструктора. Фреймворк освоює вприскування конструктора (як у прикладі), а також введення методу та поля. Це означає, що Guice може також використовувати будь-які анотовані методи або вводити їх безпосередньо в атрибут:

Ін'єкційні елементи - це примітивні типи, такі як int або char, а також перелічення та, загалом, екземпляри будь-якого класу.

Тестовий сценарій можна додатково спростити, обійшовшись без модуля планувальника з його прив'язкою та вказавши прив'язку за замовчуванням в інтерфейсі, використовуючи анотацію @ImplementedBy:

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

Частина кожного прив'язки - це постачальник, який надає екземпляри зареєстрованого класу. У деяких випадках може бути корисно або неминуче створювати об'єкти самостійно, а не залишати це внутрішньому стандарту. Якщо ви використовуєте сторонню бібліотеку, наприклад, там не можна ввести анотацію @Inject. За допомогою спеціального постачальника все ще можливо здійснити прив'язку. Спеціальні провайдери також дозволяють інтегрувати об'єкти, що доставляються через JNDI або JMX.

Інжектор як ключовий елемент

Не бійтеся ін’єкцій

Ключовим елементом у структурі Guice є форсунка, яка управляє прив’язками (рис. 2). Останні використовують анотацію на цілі ін’єкції та відносяться до типу, який потрібно вводити. Постачальник створює екземпляри типу. Обсяг прив'язки є необов'язковою специфікацією і контролює повторне використання генерованих та ін'єктованих об'єктів. Для кожного введення Guice зазвичай створює новий екземпляр відповідного об’єкта. Альтернативні сфери дії - "Singleton", "Request" і "Session".

Окрім основних описаних механізмів, Гіс знає ряд додаткових варіантів. Сюди входить визначення власних анотацій, які, наприклад, дозволяють додатково призначити бронювання рейсів та оренди автомобілів.

Коли ви чуєте ін’єкцію залежності або інверсію контролю, ви зазвичай спочатку думаєте про весну. Не без поважних причин, адже саме де-факто стандарт має активну спільноту. Як уже зазначалося, незважаючи на своє існування, Google вбачає потребу у власному рішенні. Такі альтернативи, як JBoss Seam, Apache HiveMind або Pico-Container, не завадили компанії розвиватися власними силами.

Обидва фреймворки - Spring та Guice - належать до продуктів з відкритим кодом та мають ліцензію Apache 2.0. Анотації та дженерики як компоненти Guice дозволяють використовувати лише з Java 5. Це не стосується Spring, його навіть можна використовувати з JDK 1.3 і пропонує значно більше функцій, ніж Guice. Хоча останній фокусується на DI, Spring також підтримує транзакції, наполегливість і має власну веб-структуру. Субпроекти існують для конфігурації, безпеки, пакетних завдань та декількох інших.

Визначення залежностей між об'єктами утворює основу середовища DI. Характерною особливістю є те, як зберігаються та оцінюються залежності (підключення об’єктів). Це свідчить про ще одну велику різницю між Весною та Гіс. Пружина дозволяє як чітке відображення, так і автоматичне підключення. Guice застосовує інший підхід: хоча він покладається на явне подання, він обходить балакучий формат XML, включаючи відносини у вихідний код за допомогою анотацій Java. Цю процедуру можна розуміти як суміш між докладним, але тривалим технічним обслуговуванням, явним поданням та автоматичним підключенням. Spring також дозволяє створювати залежності в коді Java за допомогою JavaConfig, але цей підпроект все ще перебуває у етапі етапу.

продуктивність

Маленький, швидкий, чіткий

Guice демонструє свої переваги щодо продуктивності перед Spring як під час запуску програми, так і під час виконання, коли йдеться про створення запитуваних об’єктів. Guice досягає лідируючих позицій при створенні об’єктів завдяки можливостям одночасності Java 5. (Однак це має змінитися з Spring 3, який буде повністю заснований на Java 5.) Крім того, він не генерує проксі-об'єкти, які використовує Spring. Однак наскільки це актуально на практиці, залежить від характеру заявки.

Окрім технічних властивостей та діапазону функцій, при виборі інструменту важливі такі аспекти, як складність. Google чітко бачить, що Guice має перевагу над Spring з точки зору простоти, чіткості, ремонтопридатності, навчальності та продуктивності.

Загалом, численні порівняння двох рамок викликали ажіотаж у відповідних колах. Врешті-решт, це не зводиться до рішення або-або, оскільки, хоча обидва контейнери DI, вони мають різну спрямованість: Guice залишає невеликий «слід», тоді як Spring пропонує себе як комплексне та потужне рішення. Значна частина його XML-складності також зумовлена функціями поза DI. Оскільки Guice не охоплює ці сфери, справжнього суперництва немає. Співіснування обох фреймворків можливо, оскільки Guice дозволяє інтегрувати Spring Beans.

План для Guice 2, запланований на січень 2009 року, містить низку вдосконалень, включаючи прослуховувачі конструкції та API самоаналізу. Слухачі пропонують точки входу під час створення об’єктів, щоб зачепити власну логіку. Розширення API призначене для викриття внутрішніх елементів об'єкта Injector та надання повного доступу до графіку залежностей. Наприклад, це забезпечить вихідну точку для інструментів візуалізації. Дорожня карта також називає методи провайдера, за допомогою яких класи модулів можуть бути спроектовані легше. Таким чином, замовники можуть здійснити більш гнучке прив'язування, яке ефективно, наприклад, лише в певному обсязі.

Висновок

Не спалахнув на сковороді

Guice все ще новий, тому поза Google не існує продуктивних додатків. Згаданий веб-фреймворк Struts2, безумовно, є винятком. Однак досвід Google та використання AdWords гарантуватимуть, що Guice не закінчиться спалахом. Сторінні модулі, які зараз існують, є ще одним свідченням цього. Сюди входять компоненти, що дозволяють Guice взаємодіяти з Hibernate або DWR фреймворка Ajax.

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

Тобіас Люттіке
працює архітектором рішень у міністерстві у Веллінгтоні, Нова Зеландія.

Крістіан Медер
є старшим архітектором inovex GmbH у Пфорцгаймі.

глосарій

Код таблички: Повторювана, але необхідна схема F-коду, яка не відображає ділової логіки.

Інжектор: Компонент, який виконує залежність, вводячи потрібний об'єкт.

Модуль: Контейнер для прив'язок, який визначає, що слід вводити.

Зв'язування: Зв'язок між інтерфейсом та його реалізацією.

Сфера застосування: Область введення об’єкта (наприклад, запит, сеанс, одиночний).

(Спеціальний) Постачальник: Створює об’єкти для ін’єкції. У варіанті "Спеціальний" для індивідуального підключення не застосовуваних компонентів.

Завантаження: Ініціалізація Guice шляхом впорскування кореневого об’єкта для того, щоб запустити автоматичне підключення. Це дозволяє уникнути необхідності повторно допитувати інжектор пізніше для кожної ін’єкції.

Анотації: Мета-інформація, яку розробник зберігає у вихідному коді класів Java із попереднім символом "@".

Дженерики: Методи та класи, які можна параметризувати за допомогою параметрів типу.

Добре підключений

Проводка описує спосіб, яким фреймворк управляє залежностями між об’єктами. Існує дві основні форми: явне представлення в XML або Java та автоматична оцінка фреймворком під час виконання (автоматичне підключення). Обидва варіанти можна оцінити. У випадку автоматичного підключення, фреймворк намагається зрозуміти взаємозв'язки між самими компонентами. Однак зі збільшенням складності програми це створює проблему: продуктивність погіршується і погіршується.

Вільні стосунки

Інжекція залежностей (DI) - популярне поняття при розробці програмного забезпечення. Дві основні цілі: спростити повторне використання та обслуговування програмного забезпечення шляхом вільного з’єднання компонентів та полегшити тестування.

Коли об’єкт A містить посилання на об’єкт B, він зазвичай знає його реалізацію. Концепція DI передбачає, що залежності між абонентом A та цілями B, на які він звертається, більше не зберігаються в A. Абонент інформується лише за необхідності, яка реалізація цільового об'єкта B конкретно повинна бути розглянута. Для цього в А «вводять» відношення до бетону В. Як абонент, А не знає цільовий об'єкт, який буде використаний до остаточного введення.

DI - це парадигма інверсії контролю (IoC), також відома як Голлівудський принцип: не дзвоніть нам, ми зателефонуємо вам. Таким чином, введення залежностей дозволяє використовувати різні сценарії використання без необхідності адаптувати для цього вихідний код абонента, наприклад, коли додаються нові реалізації цільових об'єктів. Поширеним прикладом такої подальшої мети є послуга як спрощений варіант оригінальної послуги для тестових цілей. Якщо фактичний сервіс потребує великих ресурсів і працює тривалий час або взагалі доступний лише у виробничому середовищі, реалізація як макетний об'єкт (фіктивний) дозволяє (швидше) тестувати.