This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: How J2EE Killed Object-oriented Programming
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
First off, let me say that I've been using Java and J2EE technologies since 1996. I'm a fan. But the combination of Web technologies and EJB components threatens to squeeze the last vestiges of OO out of enterprise Java development.
"Come on, you're overstating the case," I can already hear you saying. But am I? Consider this: a state of the art enterprise architecture for a basic Java web-based application typically consists of:
A business services layer, consisting of a collection of procedural methods. Things like "transferBalance( AccountVO, AmountVO)" are the norm. These are often session beans, and they have more in common with database stored procedures than those polymorphic, data hiding, inheritance-loving mixtures of data and behavior of yesteryear.
An object-relational mapping layer, either Entity Beans, Hibernate, or a custom Data Access Object layer. Again, not much in the way of first class objects, these are really just mechanisms for mapping to the database. They are often auto-generated, and rarely exhibit any significant behavior. You know, the non-data part of OOP.
A presentation layer, usually some sort of MVC framework like Struts. Wait, there might be some objects here...except for the lack of reusability, portability, and the exposure of implementation details of the Web environment like HttpSession objects. Objects in name, but not in spirit.
A whole bunch of Value Objects - data structures with getters and setters that do nothing else.
And with the advent of AJAX, there's even less componentization, as bits of JavaScript make a play for first-class status in the development stack.
Now, to be fair, there are some technologies such as the Spring framework, maybe Tapestry, that encourage traditional OO development instead of exposing implementation details all over the show. And yes, Hibernate and EJB 3.0 might improve the "objectness" of domain objects a little bit.
But for many Java developers, their world is a sea of acronyms, framework, and layers that have nary a classic Object in sight. What ever happened to "smart" objects that actually did something useful, had interesting behavior, and didn't expose their implementation details to the whole world?
So whose fault is this, you ask? It's a bit like a frog being boiled, I'm afraid. These "best practices" and "patterns" in the J2EE space have slowly moved us from skilled objected-oriented developers to code-generating, 20-minute-Ant-build-running, WAR-file-deploying shells of humanity, desperate for a real object to sink our teeth into.
But maybe these practices are the right way, and OOP was overrated? Maybe, but something smells funny about that. Are we any more productive than we were 5 years ago when the bulk of Java enterprise technologies came on the scene? Is it easier to write applications in Java? Are they more maintainable than a few years back?
I'm not saying Java stinks, it's not the language or the platform that's the problem here. There are plenty of tools in the tool bucket to create robust, scalable, and performant applications in "classic" object-oriented fashion.
But I fear that the last 5 years has produced a pile of brittle, over-engineered applications whose internals are exposed. Today's J2EE applications might look a lot like yesterday's procedural COBOL applications that were so derided by upstart Java developers 10 years ago.
The way forward is to go backwards to the first principles of development. Keep it simple. Don't repeat yourself. Don't build complexity you're not sure you'll need. Don't expose implementation details outside the components that rely on them. Patterns are not how-to guides, they're just documentation of things that occur in the wild, along with the forces and consequences of their existence.
This isn't about attacking Java or Java developers - the same can be said for .Net, PHP, Perl, and a whole host of other approaches. It is a challenge to creators of the next generation of applications, frameworks, and tools. We can do better. It's time to start.
For more on agile tools and techniques: http://www.extremeplanner.com
Previous Topic
