Most J2EE development is in DP style That does not mean that you cannot do Object Oriented J2EE. But what people do with a language creates the language culture. Perhaps some people could build OO programs in a culture of DP, but it will always be fighting against the norm.
You can certainly build OO designs with java. Lot of people do. Often however, requirements are presented in terms of DP vocabulary. This makes building it in OO more difficult for the users to understand.
DP is encouraged when requirements:
* Specify the screens
* Specify the DB schema
* Specify the data fields, flags, switches, and codes
* Specify the data transformations.
Fitting that into an OO mold is another impedance mismatch.
OO requirements would
* talk in Business terms
* Name the concepts involved (Classes)
* Iterate furiously to refine understanding, and reduce concepts to a minimum
* define and place behavior (not data) into and among the classes
This requires business uses to talk in business language. However, I'm noticing that most Business users are now talking in terms of data and processing. Not in their own native business language.
Many Business users speak DP. They expect DP solutions.
So, to really do OO, the upstream expectation need to be broadened. The business users need to speak in their native language of concepts again. This is a switch in culture. And will be difficult.
The first step is for us Java folks to understand that what we have often been delivering is not OO. But at the core of most J2EE systems are data structures and processes, hence DP-style.
Much of the common literature in Java has encouraged this. The J2EE blue prints, Struts, Entity Beans, etc. These all encourage a DP approach.
So to do OO in J2EE, is often swimming against a powerful set of fundamental assumptions, and frameworks. Thats why I'm exploring the Ruby language and culture. The assumptions in Ruby are tilted heavily toward Object Orientation.
I worry that trying to do OO in J2EE will often make one a frustrated outsider.
