Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14059

Re: Learning Java

Show all headers | View raw

On 12-04-29 08:34 PM, markspace wrote:
> On 4/29/2012 7:00 AM, Arved Sandstrom wrote:
>> What's been missing is a
>> general acknowledgement that we write a *lot* of procedural Java code,
>> and maybe work on ways to formalize how to do that well. DCI is one
>> approach.
> 
> 
> Hmm, perhaps.  However, I had to learn OOD on my own (I graduated before
> it came fully into vogue), and I've always been keenly aware that the
> need for procedural code in OOD seems to be general accepted.

I don't get that same sense. I think programmers understand, when
looking at any method, that it's a chunk of _imperative_ code. You can't
avoid that in either procedural or OO code - imperative is what we've got.

Let's not lose sight of one major distinction between procedural and
object-oriented. In procedural we write procedures to operate on data,
and in OO we write data that can operate on itself.

I believe that anemic domain objects are legit OO if they truly have
little or no interesting behaviour. That is not exactly rare. You can't
blame a class for just having accessors if it's a really boring class.

What I do have a problem with are anemic domain objects that ought to
have behaviour, but that logic is parked somewhere else. That is now
procedural code and it's bad procedural code.

Example: why do so many people insist on leaving their JPA entity
classes anemic? Practically all available code examples foster this
impression, and the Java EE tutorial itself promotes this idea by
describing entities as "lightweight persistence domain object". Is there
actually a law that says that these particular domain classes can't be
given behaviour? Well, people sure think so, which is why you end up
with reams of code that operates on data structures (entity objects).
You often see people writing *Util classes that have methods to work on
JPA entities...just because they believe these are "special" objects.
Well, yeah, they are special, but not _that_ special.

To be fair, the Java EE tutorial also says that "Clients must access the
entity’s state through accessor or business methods." Thus indicating
that you can in fact have business methods in JPA entity classes. I just
don't see that a lot of programmers ever read that bit.

I don't agree with everything Adam Bien says, but in
http://www.javaworld.com/javaworld/jw-05-2009/jw-05-domain-driven-design.html
he notes that

"The vast majority of J2EE and Java EE applications are built in a
procedural way. The business logic is decomposed into tasks and
resources, which map, respectively, to services and anemic, persistent
entities. Such an approach works surprisingly well until type-specific
behavior for domain objects must be realized. Then the lack of object
orientation in the persistence layer can cause problems."

My argument is that many Java programmers end up precisely where Bien
describes, and like Bien says this often works quite well, but I sure
don't get the sense that they understand that this is procedural code.
They think it's OO - it's the terminology you hear.

Adam Bien notes that there is another possibility, a "lean" architecture
(http://www.javaworld.com/javaworld/jw-04-2009/jw-04-lean-soa-with-javaee6.html).
This focuses on SOA services. This has anemic domain objects but has the
virtue of having a reasoned argument behind it. I am not maybe 100%
behind it myself but at least there's a rationale.

Coplien and Bjornvig have obviously their book on "Lean Architecture",
where DCI figures strongly. This is a recognition that apps written in
an OO language contain a great deal of true procedural code, and DCI is
a system for imposing discipline on that, based on contextually
(use-case) making rich objects from anemic ones as needed, and letting
them interact with that runtime behaviour. DCI and what Bien presents
are different, but they both provide a rationale for recognizing and
formalizing procedural code in a nominally OO application.

> To go back to one of the earliest sources, if you pick up a copy of
> Bjarne Stroustrup's The C++ Language, there's a chapter (#23) that
> explains his basic OOD philosophy.  As a pedagogical example, he designs
> a simple parser.
> 
> First, he makes some simple objects that correspond to the leaf nodes in
> a parse tree.  Then he designs the actual tree itself.  Then he says
> "Now I need to make it DO something."  And he makes a class that he
> calls a "driver" which is all procedural code and implements the actual
> use cases of his simple parser, using the objects he previously created.
> 
> Iirc the Rational design process has a similar division.  I personally
> see procedural elements in design patterns like MVC, where the
> controllers appear to me to be simply drivers like Stroustrup's driver
> (although controllers do preform a more specialized kind of procedural
> function).  I think Arne post here a while back about a design pattern
> that recognized procedural bits in an overall design pattern and called
> them "services."  Etc.

Sure enough. I don't recall Arne's post offhand, but Bien's lean
architecture is similar I suspect.

I don't have a problem with procedural. I know that much, sometimes
most, of application logic _is_ procedural. I'm all over procedural. :-)
That's why I am so interested in DCI or anything else that offers a
decent thought process and techniques for being deliberate and
systematic with the procedural code.

And I am still a big fan of rich domain objects. I think - and DCI
advocates this - that if there is logic which is truly domain logic that
belongs to a class, that you jam it in that class. To return to JPA
entities, it's just wrong that if you've got hundreds of entity classes
that *none* of them have any business methods.

> I think procedural method in OOD are recognized, but the may not be
> specifically called out.  It's assumed that you just recognize "Oh
> s/he's writing some procedural code here."  A lot of writing requires
> the user to make a judgement how procedural needs to be, and design
> appropriately.  Reference objects tend to have longer procedural bits,
> but that doesn't obviate the need for pure procedural code when
> required.  App start up and shutdown, for example, tend to be purely
> procedural, and there's not reason to make them otherwise.
> 

But here's the thing. If you start out the way Bien suggests a lot of
folks start out, by thinking procedural from the gitgo, you end up with
way more procedural than is right. And this is the kind of Java coding I
usually see.

AHS
-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Learning Java Steve Graham <jsgrahamus@yahoo.com> - 2012-04-17 15:03 -0600
  Re: Learning Java markspace <-@.> - 2012-04-17 14:33 -0700
    Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-17 21:50 +0000
      Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 19:21 -0400
      Re: Learning Java markspace <-@.> - 2012-04-17 16:47 -0700
        Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-18 02:30 +0000
          Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-28 21:56 -0400
      Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-17 21:07 -0300
        Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 22:06 -0400
          Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-18 07:11 -0300
            Re: Learning Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-18 06:47 -0500
            Re: Learning Java Lew <lewbloch@gmail.com> - 2012-04-18 10:19 -0700
              Re: Learning Java Lew <lewbloch@gmail.com> - 2012-04-18 10:20 -0700
            Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-18 21:10 +0000
            Re: Learning Java Gene Wirchenko <genew@ocis.net> - 2012-04-18 15:01 -0700
            Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-28 22:11 -0400
              Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-29 11:00 -0300
                Re: Learning Java Lew <noone@lewscanon.com> - 2012-04-29 11:44 -0700
                Re: Learning Java markspace <-@.> - 2012-04-29 16:34 -0700
                Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-30 20:52 -0300
                Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 18:17 -0400
                Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-06 15:49 -0300
                Re: Learning Java Gene Wirchenko <genew@ocis.net> - 2012-05-07 09:50 -0700
      Re: Learning Java RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2012-04-19 15:30 +0100
  Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 19:26 -0400
  Re: Learning Java Patricia Shanahan <pats@acm.org> - 2012-04-17 19:08 -0700
  Re: Learning Java Roedy Green <see_website@mindprod.com.invalid> - 2012-04-26 16:06 -0700
  Re: Learning Java Steve Graham <jsgrahamus@yahoo.com> - 2012-05-15 17:40 -0600

csiph-web