 |
|
 |
 |
|
|
 
Bruce Tate's BlogTime, wisdom and AOPPosted by batate on October 13, 2004 at 01:27 PM | Comments (7)I'm teaching a programming symposium on most weekends called nofluffjuststuff. I've had the opportunity to attend some excellent classes by my peers. One of my favorite was given by Nicholas Lesiecki, on using AOP in main stream projects. He contends that AOP is here, ready for prime-time today. He provided some persuasive examples of how his team used AOP in real-world projects to solve crosscutting problems. (If you ever get the chance to hear him speak, I'd recommend it.) I've long said that we're not ready as an industry to move to AOP, and others share that view. Why the disconnect? In another session, Dave Thomas (Pragmatic Dave) spoke about the learning patterns of programmers as they make the journey from novice to expert. I won't give away the talk, but the gist is that as we grow as developers, we learn in different ways, and progress from thinking in steps to thinking abstractly. We can increasingly put experience in context, and use the experience of others. I agree with this premise. Here's my leap of insight. I think that we, as an industry, need to move through a very similar progression before we move on to a new programming paradigm. I think that we need to build that collective wisdom that only time and experience can bring. Sure, we need to succeed, and fly high. But we also need to crash a few times, and have the time to collectively pick through the wreckage and understand what's gone wrong. We need to establish how far we can push AOP (like we needed to learn how far to push inheritance.) We need to understand what constructs work (like programming to interfaces) and those that might not (like intercepting property accesses, or introductions, or advising an aspect.) How do we package? How will an approach hold up over time? How easy is it to maintain? How do we have a visual clue that something is advised? Do we need a clue? Here's the thing. We've got 40 years of history to study the emergence of new paradigms. We can look in the rear view mirror and understand the same process for object technology, or structured programming, or high level languages. From a distance, it always looks like we move forward in surges, and stay stagnent for decades. It's not really that way, though. If you take a closer look, you can see the individual tiny little surges when we try slices of a new paradigm before we actually get it right. For example, a few people succeeded with SmallTalk, but the mainstream could not make it work. We were never able to make it succeed on a broader scale, maybe because it was too alien, and maybe because it was too tightly coupled to the smalltalk environments. But others tried to make objects fly in limited ways, like Ada and encapsulation, or like COM components and aggregation. It finally took an adaptation of a procedural language, C to C++, to give us a safe environment. C++ was safe because you could write oo code, and retreat to procedural code when you needed to. Sure, most of us wound up writing procedural code, but with the combined experience and community, we were finally ready for objects when Java burst onto the scene. So my premise is that we need to look for ways to use AOP with training wheels. We'll see limited techniques that simulate AOP behavior, like interceptors. We'll see frameworks that let you configure prepackaged AOP services, like Spring. With technologies like these, we'll be able to use limited AOP power, and get some limited benefit. All of this time, we can more safely collect the wisdom that will make it possible to push AOP from small, expert-laden successful projects to the mainstream. It's all about collecting wisdom. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
