Java и внедрение защитных копий - PullRequest
Новая
       28

Java и внедрение защитных копий

0 голосов
/ 13 октября 2011

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

Под этим я подразумеваю, что до того, как меня представили в AOP, я бы вручную проверил аргументы для всех своих методов, например: 

public void doSomething(final int p_iAge, final Widget p_oWidget)
        throws IllegalArgumentException
{
    if(p_oWidget == null)
        throw new IllegalArgumentException();

    // ...
}

Теперь я использую Apache Bean Validator для проверки своих методов, и все возникающие исключения я обрабатываю с помощью AOP. Это хорошо очищает мой код и отделяет мою бизнес-логику (что меня действительно интересует!) От скучной, скучной проверки правильности, выдачи исключений и т. Д.

Но теперь, когда мне начинает нравиться концепция создания защитных копий, я начинаю выбирать правильные методы, которые снова выглядят одинаково: 

@NotNull(message="Widget cannot be null.")
public void doSomething(final int p_iAge, final Widget p_oWidget)
{
    Widget oWidget = new Widget(p_oWidget);

    // ...
}

Итак, мой вопрос:

Существует ли де-факто способ использования AOP / IoC (любой фреймворк! - я в отчаянии!) Для написания совета / pointcuts, который выделит эту скучную, утомительную (ха!) Задачу написания вручную защитные копии и внедрение их обратно в локальный (метод) объект? Таким образом, я мог бы получить преимущества безопасности защитных копий при всей чистоте AOP / IoC.

Я полагаю, что мне пришлось бы написать совет, который перехватывает все методы и использует внедрение зависимостей, чтобы каким-то образом создавать объединенные / управляемые экземпляры параметров этих методов; эти экземпляры будут защитными копиями. Затем, вернувшись в свои целевые классы, я мог использовать IoC, чтобы получить доступ к этим защитным копиям (бобам).

В соответствии с этой (общей) парадигмой, я думаю, что код будет выглядеть следующим образом: 

@NotNull(message="Widget cannot be null.")
public void doSomething(final int p_iAge, final Widget p_oWidget)
{
    // By the time we get here, bean validation has already made sure
    // that p_oWidget isn't null, and the AOP method interceptor has already
    // executed and created the "defensive-widget" bean.
    Widget oWidget = springOrWhateverInjector.getBean("defensive-widget");

    // ...
}

Теперь , oWidget является защитной копией p_oWidget, и мне не нужно писать ее вручную. Огромная экономия времени, и мой OCD с AOP доволен!

Но я даже не уверен, поддерживают ли такие концепции AOP, как AspectJ / AOP Alliance и IoC, такие как Spring или Guice.

Я также испытываю огромное уважение к сообществу SO и хотел бы получить общий вклад здесь - комментарии / рекомендации / и т.д. Заранее спасибо!

1 Ответ

1 голос
/ 13 октября 2011

Совет AspectJ вокруг позволяет указывать собственные параметры для перехваченного метода при использовании ProceedingJoinPoint # continue (Object []) .

В этом совете вы можете проверить, является ли данный параметр копируемым - в вашем случае, используя отражение, чтобы найти объявленный конструктор, который принимает единственный параметр типа объекта, или как бы то ни было, выберите отметку объектов, которые вы хотите сделать защитными копиями - и затем продолжите метод, используя копии вместо исходных параметров.

...