4 ms·
Different people have very different views on this. It seems to be something which touches at an emotional level, or just exposes the way different people think
by fmstephe 13y ago
Different people have very different views on this. It seems to be something which touches at an emotional level, or just exposes the way different people think about programming.
My opinion is that aspects are a mistake in general. I think that all of the situations that I have seen aspects used they have saved roughly 5 lines of boiler plate in exchange for creating an invisible layer of very fragile code which ties you hard to your Spring container.
But I really like explicit code, so you would expect me not to like aspects. I do strongly think that aspects are really solving a 'not very hard' problem while exacerbating the biggest problem I have, which is not understanding the codebase.
The thing I truly hate about Spring are the stacks. Good lord, I cannot find my code in that skyscraper of abstract proxied garbage. If you want a good technical reason to dislike Spring it's good to note that deep stacks place a larger burden on your garbage collector, in this instance Spring is truly a degenerate case.
W.r.t. gclib I don't want my code byte weaved. Ever. I want it to do what is says on the tin. Always. I am very willing to write and read more code to do this. If too much code is becoming a problem don't turn to Spring - try removing some of your AbstractFactoryFactories first :) (tongue sort of in cheek)
- chris_wot 13y agoFair points. At least you have a reasoned argument :-)
- fmstephe 13y agoIt took me a while to build up to a well reasoned argument :) Since I work with Spring every day it brings up some strong emotions.
- mtrimpe 13y agoIf you don't like DI or AOP, then you can just code plain Java. If you like DI but not AOP, then something like Guice or plain Java and some self-discipline would probably work better for you. If you like DI and AOP, then you can let Spring get you as close to proper AOP as Java allows without weaving, or you can use the same syntax to do compile-time weaving to get a non-leaky abstraction All these are just choices to make; it seems like you're more fighting against the fact that you don't like how the 'industry' is making these 'enterprise standard' choices for you. On a technical level it's more like criticising Rails for using meta-programming everywhere, or C because it's so low-level (i.e. that's what they were designed for! If that's not what you need, don't use it!)