开发者

Java and Injecting Defensive Copies

开发者 https://www.devze.com 2023-04-13 08:58 出处:网络
So I\'m starting to really like the concept of defensive copies for the purpose of making code more \"secure\", but unfortunately they seem to inherently conflict with the wonderful separation of conc

So I'm starting to really like the concept of defensive copies for the purpose of making code more "secure", but unfortunately they seem to inherently conflict with the wonderful separation of concerns addressed by AOP.

By this, I mean that before I was introduced to AOP, I would manually validate the arguments to all my methods, like so:

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

    // ...
}

Now I use Apache Bean Validator to validate my methods, and any exception that gets thrown I handle via AOP. This cleans my code up nicely and separates my business logic (what I'm really interested in!) from the dull, boring validation checking, exception throwing, etc.

But now that I'm starting to like the concept of making defensive copies, I'm starting to right methods that all look the same again:

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

    // ...
}

So, my question:

Is there a de facto way of using AOP/IoC (any framework! - I'm desperate!) to write advice/pointcuts that will separate-out this dull, arduous (ha!) task of manually writing defensive copies and injecting them back into a local (method) object? That way, I could get the security benefits of defensive copies, with all开发者_Python百科 the cleanliness of AOP/IoC.

I imagine that I would have to write advice that intercepts all methods and that uses dependency injection to somehow create pooled/managed instances of that methods parameters; these instances would be the defensive copies. Then, back in my target classes, I could use IoC to gain access to these defensive copies (beans).

Under this (general) paradigm, I imagine the code would then look like this:

@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");

    // ...
}

Now, oWidget is a defensive copy of p_oWidget, and I don't have to manually write it. Huge time savings, and my OCD with AOP is satisfied!

But I'm not even sure if AOP frameworks like AspectJ/AOP Alliance and IoC framework like Spring or Guice would even support such a concept.

I also have an enormous amount of respect for the SO community and would like some general input here - comment/recommendations/etc. Thanks in advance!


AspectJ's around advice lets you supply your own parameters to the intercepted method when using ProceedingJoinPoint#proceed(Object[]).

In the advice, you could check if a given parameter is copyable – in your case, using reflection to find a declared constructor that takes a single parameter of the type of the object, or however else you choose to mark objects that you want to make defensive copies of – and then proceed with the method using the copies instead of the original parameters.

0

精彩评论

暂无评论...
验证码 换一张
取 消