Plain Old Java COMPONENTS
I've been reading about the various proposals for adding properties and events to the Java language. In the process, I stumbled across an interesting blog entry by Richard Bair which he starts by describing why JavaBeans don't break encapsulation. For a long time, I've believed Javabeans were an abomination. Despite the intentions of the creators a technology is eventually defined by how it is used. With the exception of a couple dozen Swing components, the JavaBeans patterns is used by most developers as a loophole allowing programmers to break encapsulation.
When Richard describes the original purpose of JavaBeans, he's describing a framework that was needed very badly for allowing tools to interact with components. If properties and events are added to the language, it would go a long way towards cleaning up the interface between components and their tools.
What I don't see it helping with, however is the programmer's understanding of what they are doing when they make a component. When someone implements the JavaBean pattern, they are agreeing to an existing contract. I know very few programmers who understand that contract. None of them seem to understand that they are building a component. They have been told by the good people at Hibernate or the people who made their databinding framework that they were making plain-old-java-OBJECTS.
Plain Old Java Objects. Like every other Java object out there. But Hibernate doesn't work with just any Java object, does it? It only works with Java objects that strictly meet the contract set by the JavaBeans pattern.
Of course the market has picked the term POJO to emphasize the difference between today's tools and those requiring implementation of multiple interfaces and the addition of specific behaviors to your objects. As horrible as those frameworks were, they were object-oriented. Of course, since the buzz of the term object-oriented hasn't died down, we don't want to tell people that we've transitioned them to component-oriented programming already.
When Richard describes the original purpose of JavaBeans, he's describing a framework that was needed very badly for allowing tools to interact with components. If properties and events are added to the language, it would go a long way towards cleaning up the interface between components and their tools.
What I don't see it helping with, however is the programmer's understanding of what they are doing when they make a component. When someone implements the JavaBean pattern, they are agreeing to an existing contract. I know very few programmers who understand that contract. None of them seem to understand that they are building a component. They have been told by the good people at Hibernate or the people who made their databinding framework that they were making plain-old-java-OBJECTS.
Plain Old Java Objects. Like every other Java object out there. But Hibernate doesn't work with just any Java object, does it? It only works with Java objects that strictly meet the contract set by the JavaBeans pattern.
Of course the market has picked the term POJO to emphasize the difference between today's tools and those requiring implementation of multiple interfaces and the addition of specific behaviors to your objects. As horrible as those frameworks were, they were object-oriented. Of course, since the buzz of the term object-oriented hasn't died down, we don't want to tell people that we've transitioned them to component-oriented programming already.
Labels: Programming
posted by Bryan at
8:24 AM
0 Comments:
Post a Comment
<< Home