Hi!
David Newton wrote:Hmm, I see-that's an interesting approach. For me this isn't really what aspects are for, I guess.
Well, I used to have similar feelings until I saw how Spring Roo uses Inter-Type Declarations. ITD was one feature of AspectJ that I had, more or less, overlooked until I begun with my current experiment.
It also allows me to add environment-specific behaviour or data to a class from a common library.
Example: I have a class Foo that is used both on the client and server side of some application. Foo is located in a library that is used by both the client and server. However, on the server side Foo needs to have some functionality, or contain some data, that is specific to the server side and does not apply to the client side. I can use ITD to add the desired data/behaviour in the server application, without having to modify the common library.
Perhaps such situations are a sign of poor design or something else. Regardless, I have experienced situations in which I could have had use for the the above technique, had I known more.
For example, to "eliminate" getters and setters, when I need to, I just create base classes...
Yes, this is also a feasible approach and I have used it on occasions.
Similarly validation--if I was going to make that into an aspect I'd be more likely to make the validation *execution* an aspect, but the validation logic itself would be either in a base class, or in an injectable implementation, etc.
In this case it is the framework, Naked Objects, that sets the rules regarding how to implement validation methods. As far as I understand, the best I can do in order not to mix validation with business logic is extracting the validation to an aspect that uses ITD.
I'll prepare a small example and post it later. It would be interesting to hear your thoughts on it.
Best wishes!