Является ли хорошей идеей использовать аспекты как метод удаления защитных проверок из логики приложения? - PullRequest
Новая
       2

Является ли хорошей идеей использовать аспекты как метод удаления защитных проверок из логики приложения?

8 голосов
/ 17 февраля 2012

Вид длинного заголовка, но это, как правило, вопрос.

Я хочу знать, считаете ли вы хорошей идеей сделать следующее.

Вместо: 

public void buyItem(int itemId, int buyerId) {
    if (itemId <= 0) {

        throw new IlleglArgumentException("itemId must be positive");
    }
    if (buyerId <= 0) {

        throw new IlleglArgumentException("buyerId must be positive");
    }
    // buy logic
}

Я хочу что-то вроде: 

@Defensive("isPositive(#itemId, #buyerId)")
public void buyItem(int itemId, int buyerId) {
    // buy logic
}

Как вы думаете, это хорошо / ужасно / слишком необычно / слишком медленно?Если вы действительно думаете, что это хорошо, я подумал об использовании SpEL для его реализации, есть ли у кого-нибудь что-то лучше / легче / быстрее?

Спасибо,

Ответы [ 5 ]

3 голосов
/ 17 февраля 2012

Это не обязательно плохо, однако ваш простой случай вполне может быть решен с помощью исключений утверждений ( вместо утверждений , которые я изначально упоминал).

Кажется, вы вводите свой собственный набор аннотаций, которые другие разработчики в вашем проекте должны принять и адаптировать к ним.Тем не менее, после того, как вы ввели аннотации, кажется, что обычный подход Proxy будет лучшим кандидатом для решения проблемы.

Подводя итог: проблему, которую вы описали, можно легко решить, используя стандартные альтернативы Java, хотя в более сложном случае это может быть оправдано (например, @Secured в Spring-Security), особенно если вы 'Вы разрабатываете собственную среду .

2 голосов
/ 17 февраля 2012

Я думаю, что вы имели в виду аннотации, а не аспекты. Аспекты обычно являются внешними по отношению к коду, который они советуют. В любом случае вы можете выполнить тот тип проверок, который вы выделили в своем сообщении с помощью JSR 303 . Показательный пример: 

public void buyItem(@Min(value = 1) int itemId, @Min(value = 1) int buyerId) {
    // buy logic
}

В настоящее время существует две хорошо известные реализации JSR 303:

2 голосов
/ 17 февраля 2012

Я думаю, что это

  • переустройства
  • нарушение инкапсуляции, полагаясь на внешний аспект (который мог или не мог быть там) для поддержки инвариантов объекта
  • запутанным
  • неэффективно
  • без добавления значения

Мне нравится использовать класс предварительных условий Guava для таких проверок. Более того, такие проверки являются частью бизнес-логики, ИМХО.

1 голос
/ 17 февраля 2012

Похоже, проверка . К вашему сведению, несколько рамок уже существуют, посмотрите этот вопрос и OVal , например.

Я не знаю о спектаклях, но для меня это не чрезмерная инженерия: вы сохраняете только логический код. Я люблю работать с этим.

0 голосов
/ 17 февраля 2012

Я бы предпочел подход Java .

  1. это стандартный подход, поэтому все (большинство?) Java-программисты поймут его. Автоматизированный инструмент и т. Д. Также смогут его анализировать.
  2. тебе не нужно ничего развивать самостоятельно. Я знаю, это выглядит тривиально, но эти вещи имеют привычку обостряться.

Если вы не можете продемонстрировать, что ваш подход явно лучше или делает что-то другое, я бы использовал инструменты и API, которые Java предоставляет в качестве стандарта.

...