Чистый код. Создание, анализ и рефакторинг

Теоретически возможен модульный, инкапсулированный подход к определению стратегии сохранения объектов. Однако на практике вам приходится повторять по сути одинаковый код, реализующий стратегию сохранения, во многих объектах. Для подобных областей используется термин «поперечные области ответственности». При этом инфраструктура сохранения может быть модульной, и логика предметной области, рассматриваемая в изоляции, тоже может быть модульной. Проблемы возникают в точках пересечения этих областей. Можно сказать, что подход, использованный в архитектуре EJB по отношению к сохранению объектов, безопасности и транзакциям, предвосхитил аспектно-ориентированное программирование (АОП[38]), которое представляет собой универсальный подход к восстановлению модульности для поперечных областей ответственности.

В АОП специальные модульные конструкции, называемые аспектами, определяют, в каких точках системы поведение должно меняться некоторым последовательным образом в соответствии с потребностями определенной области ответственности. Определение осуществляется на уровне декларативного или программного механизма.

В примере с сохранением объектов вы объявляете, какие объекты, атрибуты и т.д. должны сохраняться, а затем делегируете задачи сохранения своей инфраструктуре сохранения. Изменения в поведении вносятся инфраструктурой АОП без вмешательства в целевой код[39]. Рассмотрим три аспекта (или «аспекто-подобных» механизма) в Java.

Посредники

Посредники (proxies) хорошо подходят для простых ситуаций — например, для создания «оберток» для вызова методов отдельных объектов или классов. Тем не менее динамические посредники, содержащиеся в JDK, работают только с интерфейсами. Чтобы создать посредника для класса, приходится использовать библиотеки для выполнения манипуляций с байт-кодом — такие, как CGLIB, ASM или Javassist[40].

В листинге 11.3 приведена заготовка посредника JDK, обеспечивающего поддержку сохранения объектов в нашем приложении Bank (представлены только методы чтения/записи списка счетов).

Листинг 11.3. Пример посредника JDK

// Bank.java (подавление имен пакетов...)

import java.utils.*;

// Абстрактное представление банка.

public interface Bank {

  Collection getAccounts();

  void setAccounts(Collection accounts);

}

// BankImpl.java

import java.utils.*;

// POJO-объект ("Plain Old Java Object"), реализующий абстракцию.

public class BankImpl implements Bank {

  private List accounts;

  public Collection getAccounts() {

    return accounts;

  }

  public void setAccounts(Collection accounts) {

    this.accounts = new ArrayList();

    for (Account account: accounts) {

      this.accounts.add(account);

    }

  }

}

// BankProxyHandler.java

import java.lang.reflect.*;

import java.util.*;

// Реализация InvocationHandler, необходимая для API посредника.

public class BankProxyHandler implements InvocationHandler {

  private Bank bank;

  public BankHandler (Bank bank) {

    this.bank = bank;

  }

  // Метод, определенный в InvocationHandler

  public Object invoke(Object proxy, Method method, Object[] args)

      throws Throwable {

    String methodName = method.getName();

    if (methodName.equals("getAccounts")) {

      bank.setAccounts(getAccountsFromDatabase());

      return bank.getAccounts();

    } else if (methodName.equals("setAccounts")) {

      bank.setAccounts((Collection) args[0]);

      setAccountsToDatabase(bank.getAccounts());

      return null;

    } else {

      ...

    }

  }

  // Подробности:

  protected Collection getAccountsFromDatabase() { ... }

  protected void setAccountsToDatabase(Collection accounts) { ... }

}

// В другом месте...

Bank bank = (Bank) Proxy.newProxyInstance(