Edward Sumerfield <esumerfd@xxxxxxxxxxx> wrote:
>
> Assuming your reference to "DP style" development relates to more
> transaction oriented design, then java and C# are identical. Both can be
> used in either way.
Yes. Martin Fowler called this pattern: "Transaction Script"
To me Data Processing style also involves the use of:
* data structures (called Beans)
that have only data with gettters/setters.
* Util classes to operate on the Data Structures
* Managers, Services, and Helpers, etc, that do all the real processing.
* And global public constants that are shared by multiple
algorithms scattered across the code base.
>
> You said that "most development is in DP style". Why does this imply that a
> language is more or less biased toward that style just because that's what
> people do with it?
>
What people do with it 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.
> Why can I not apply my OO design techniques to my DP app?
>
You can.
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.
* requirements definition as behavior
* iteration
* testing
These are all deep in the Ruby way of programming.
<plug>
Ruby on Rails tutorial on March 1,
see: www.objectwind.com/xp-cinci
see also yahoo groups: xp-cincinnati
</plug>
I worry that trying to do OO in J2EE will often make
one a frustrated outsider.
> If missing the presentation has made these statements seem
> ridiculous then please ignore.
>
Not at all. Thanks for asking.
Regards,
-Mark
|