If you’ve ever inherited and then had to maintain a Java-based legacy application, then this article is for you. The author shows you how to use aspect-oriented programming (AOP) to gain an unprecedented view into the inner workings of even the most opaque of legacy applications.
this guy is a computer science graduate from iit. the number of people who are admitted to that course are about 200/year (among 100,000+ applicants/year).
Wow, do you think he might even put his program together one byte at at time like the rest of us?
What every large java legacy app needs is a big fat layer of obfuscation? Pfffft! Stuff reads like a letter to mom without it. But it’s better than object it’s aspect! What a load, a lot of academia wasted.
It seems sad that the term “legacy application” is used to describe a shaky, convoluted, obfuscated mess. In my experience programmers tend to be lazy and do not design code at a sufficient level of abstraction. This leads to code that relies on implementations instead of interfaces. In turn, this leads to a high number of unnecessary dependencies. So what starts as a design problem becomes a maintenance nightmare.
Having said that, this article is more useful that the above comments would indicate. My main problem with it is that it does not even attempt to recognize the heart of the problem, or give guidance about how to address it so that maintenance programming tasks do not become so expensive as to render them impractical. Things like design review and analysis, code reviews and testing, and the ability to refactor code without being called “unproductive” are much more effective, and are much more widely applicable, than learning AOP. Unfortunately, all too often the corporate culture is unable or unwilling to engage in these activities. 🙁