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

Groups > comp.lang.java.programmer > #13616 > unrolled thread

Learning Java

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#13616 — Learning Java

I've been a programmer for 3 decades working in mostly procedural 
languages, although I have done some work with a couple of 
object-oriented ones.

Which book would you recommend that I read to learn Java?  Obviously, I 
don't want to read a beginning programming book, nor do I want to study 
one which presupposes I know something about Java or a lot about OO 
concepts.

Thanks, Steve

[toc] | [next] | [standalone]

#13617

On 4/17/2012 2:03 PM, Steve Graham wrote:
> I've been a programmer for 3 decades working in mostly procedural
> languages, although I have done some work with a couple of
> object-oriented ones.
>
> Which book would you recommend that I read to learn Java? Obviously, I
> don't want to read a beginning programming book, nor do I want to study
> one which presupposes I know something about Java or a lot about OO
> concepts.


First, how is your object oriented programming skills?  Java really only 
provides OO options, so you're going to need to know OO decently.

To get started with Java itself, I recommend you start with the Oracle 
tutorial.  It's free and does a decent job.

<http://docs.oracle.com/javase/tutorial/>

Second, there are quite a few books.  I like O'Reilly's Learning Java. 
It starts as a basic introduction, but there's enough other information 
in the book that will last you quite a while as a reference.  It also 
has one of the better explanations of Java's generics;  that alone is 
worth the price of the book imo.

There's also Effective Java, by Joshua Bloch.  And Java Concurrency in 
Practice by Brian Goetz for a well rounded treatment of multi-threading 
in Java (very important these days).

I also took a programming course via javapassion.com.  It's a pay-for 
site now.  But the course I took would have been well worth the price 
they are asking now.  If you're a busy professional who wants to come up 
to speed more quickly, I recommend it as faster than trying to self-teach.

Beyond that... well my library is one whole bookcase of software 
engineering best practice and methodologies, Java and otherwise.  I have 
several boxes in storage of books I didn't care for.  It's a broad 
field, and important to keep up with constantly.

[toc] | [prev] | [next] | [standalone]

#13618

markspace <-@.> wrote:
> On 4/17/2012 2:03 PM, Steve Graham wrote:
>> I've been a programmer for 3 decades working in mostly procedural
>> languages, although I have done some work with a couple of
>> object-oriented ones.

>> Which book would you recommend that I read to learn Java? Obviously, I
>> don't want to read a beginning programming book, nor do I want to study
>> one which presupposes I know something about Java or a lot about OO
>> concepts.

You can do procedural programming in Java. You might find it easier
to start that way, to get used to Java, and then learn the OO stuff.

Read about static methods in any Java book, and you can pretty
easily write anything that you would in C. (It will even look
a lot like C.)

Java is much like C (to me, it is closer to C than C++ is).
If your 3 decades are in C, you should have an easy time learning
procedural Java. 

Also, you can do OO programming in a procedural language, though
it isn't quite as easy. I knew OO programs in Fortran 66 (more than
three decades ago). 

> First, how is your object oriented programming skills?  
> Java really only provides OO options, so you're going to 
> need to know OO decently.

> To get started with Java itself, I recommend you start with 
> the Oracle tutorial.  It's free and does a decent job.

> <http://docs.oracle.com/javase/tutorial/>

> Second, there are quite a few books.  I like O'Reilly's Learning Java. 
> It starts as a basic introduction, but there's enough other information 
> in the book that will last you quite a while as a reference.  It also 
> has one of the better explanations of Java's generics;  that alone is 
> worth the price of the book imo.

He can skip the chapters that are too easy, but should study
the OO parts, even if they are introductory.

(snip of more book discussion)

-- glen

[toc] | [prev] | [next] | [standalone]

#13619

On 4/17/2012 5:50 PM, glen herrmannsfeldt wrote:
> markspace<-@.>  wrote:
>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>> I've been a programmer for 3 decades working in mostly procedural
>>> languages, although I have done some work with a couple of
>>> object-oriented ones.
>
>>> Which book would you recommend that I read to learn Java? Obviously, I
>>> don't want to read a beginning programming book, nor do I want to study
>>> one which presupposes I know something about Java or a lot about OO
>>> concepts.
>
> You can do procedural programming in Java. You might find it easier
> to start that way, to get used to Java, and then learn the OO stuff.
>
> Read about static methods in any Java book, and you can pretty
> easily write anything that you would in C. (It will even look
> a lot like C.)
>
> Java is much like C (to me, it is closer to C than C++ is).
> If your 3 decades are in C, you should have an easy time learning
> procedural Java.

He could.

But I would not recommend it.

If one is to learn Java, then one should use Java the Java way.

It will not utilize the language fully and it would puzzle all
maintenance programmer to use Java the C way.

Arne

[toc] | [prev] | [next] | [standalone]

#13621

On 4/17/2012 2:50 PM, glen herrmannsfeldt wrote:

> You can do procedural programming in Java. You might find it easier
> to start that way, to get used to Java, and then learn the OO stuff.


I have to concur with Arne and wouldn't recommend that either.  I asked 
how his OO comfort level was for a reason.  If it's nil, he should also 
study OO along with Java.  If it's average to fair, he'll probably be fine.

Some specifics from the OP about what level of OOP he is comfortable 
with would help us with further recommendations.  (What books has he 
read, what has he done, etc.)

[toc] | [prev] | [next] | [standalone]

#13627

markspace <-@.> wrote:

(snip, I wrote)
>> You can do procedural programming in Java. You might find it easier
>> to start that way, to get used to Java, and then learn the OO stuff.

> I have to concur with Arne and wouldn't recommend that either.  I asked 
> how his OO comfort level was for a reason.  If it's nil, he should also 
> study OO along with Java.  If it's average to fair, he'll probably be fine.

I think it depends. OP didn't say which language(s) were used over
those decades. It might make a difference. Also, it might just be
too discouraging. Starting out procedural, one can use the ideas
one knows while learning the Java specific parts.

> Some specifics from the OP about what level of OOP he is comfortable 
> with would help us with further recommendations.  (What books has he 
> read, what has he done, etc.)

I suppose, but maybe also why he wants to learn Java. 

-- glen

[toc] | [prev] | [next] | [standalone]

#13992

On 4/17/2012 10:30 PM, glen herrmannsfeldt wrote:
> markspace<-@.>  wrote:
> (snip, I wrote)
>>> You can do procedural programming in Java. You might find it easier
>>> to start that way, to get used to Java, and then learn the OO stuff.
>
>> I have to concur with Arne and wouldn't recommend that either.  I asked
>> how his OO comfort level was for a reason.  If it's nil, he should also
>> study OO along with Java.  If it's average to fair, he'll probably be fine.
>
> I think it depends. OP didn't say which language(s) were used over
> those decades. It might make a difference. Also, it might just be
> too discouraging. Starting out procedural, one can use the ideas
> one knows while learning the Java specific parts.

But what benefit would it have? Learning to code Fortran/C in
Java is not a particular useful skill!

Arne

[toc] | [prev] | [next] | [standalone]

#13623

On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
> markspace <-@.> wrote:
>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>> I've been a programmer for 3 decades working in mostly procedural
>>> languages, although I have done some work with a couple of
>>> object-oriented ones.
> 
>>> Which book would you recommend that I read to learn Java? Obviously, I
>>> don't want to read a beginning programming book, nor do I want to study
>>> one which presupposes I know something about Java or a lot about OO
>>> concepts.
> 
> You can do procedural programming in Java. You might find it easier
> to start that way, to get used to Java, and then learn the OO stuff.

I suspect that a cold, hard analysis of all Java code written in the
past 15 years would show that the large majority of it _is_ procedural.

Fact is, Java and Objective-C and C++, to name a few OOP languages, are
generally used to write substantially imperative code, where procedures
appear as object methods. We may as well not ignore that, it's what most
OO programmers do.

Having said that, the advantage of objects and OOP shouldn't be
discounted. We simply shouldn't pretend that modern OOP isn't still
largely imperative/procedural code. If we advise the OP to learn proper
OO - and I certainly do - the fact is that in his studies he's going to
come across a stupendous amount of imperative Java. I recommend that the
OP keep this in mind. There are fine resources available for learning
the principles and theory of OOP; one simply has to remember that much
real-world code deviates substantially.
[ SNIP ]

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

[toc] | [prev] | [next] | [standalone]

#13624

On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>> markspace<-@.>  wrote:
>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>> I've been a programmer for 3 decades working in mostly procedural
>>>> languages, although I have done some work with a couple of
>>>> object-oriented ones.
>>
>>>> Which book would you recommend that I read to learn Java? Obviously, I
>>>> don't want to read a beginning programming book, nor do I want to study
>>>> one which presupposes I know something about Java or a lot about OO
>>>> concepts.
>>
>> You can do procedural programming in Java. You might find it easier
>> to start that way, to get used to Java, and then learn the OO stuff.
>
> I suspect that a cold, hard analysis of all Java code written in the
> past 15 years would show that the large majority of it _is_ procedural.
>
> Fact is, Java and Objective-C and C++, to name a few OOP languages, are
> generally used to write substantially imperative code, where procedures
> appear as object methods. We may as well not ignore that, it's what most
> OO programmers do.
>
> Having said that, the advantage of objects and OOP shouldn't be
> discounted. We simply shouldn't pretend that modern OOP isn't still
> largely imperative/procedural code. If we advise the OP to learn proper
> OO - and I certainly do - the fact is that in his studies he's going to
> come across a stupendous amount of imperative Java. I recommend that the
> OP keep this in mind. There are fine resources available for learning
> the principles and theory of OOP; one simply has to remember that much
> real-world code deviates substantially.

OOP is supposed to be imperative, so I do not see much point in that
argument.

How big a portion of Java code that is procedural will depend a
bit on where you put the bar.

If we put the bar relative low:
   procedural = all static methods
   OOP = use of interfaces, private fields public methods
then the majority of Java code is not procedural.

Arne

[toc] | [prev] | [next] | [standalone]

#13631

On 12-04-17 11:06 PM, Arne Vajhøj wrote:
> On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
>> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>>> markspace<-@.>  wrote:
>>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>> languages, although I have done some work with a couple of
>>>>> object-oriented ones.
>>>
>>>>> Which book would you recommend that I read to learn Java? Obviously, I
>>>>> don't want to read a beginning programming book, nor do I want to
>>>>> study
>>>>> one which presupposes I know something about Java or a lot about OO
>>>>> concepts.
>>>
>>> You can do procedural programming in Java. You might find it easier
>>> to start that way, to get used to Java, and then learn the OO stuff.
>>
>> I suspect that a cold, hard analysis of all Java code written in the
>> past 15 years would show that the large majority of it _is_ procedural.
>>
>> Fact is, Java and Objective-C and C++, to name a few OOP languages, are
>> generally used to write substantially imperative code, where procedures
>> appear as object methods. We may as well not ignore that, it's what most
>> OO programmers do.
>>
>> Having said that, the advantage of objects and OOP shouldn't be
>> discounted. We simply shouldn't pretend that modern OOP isn't still
>> largely imperative/procedural code. If we advise the OP to learn proper
>> OO - and I certainly do - the fact is that in his studies he's going to
>> come across a stupendous amount of imperative Java. I recommend that the
>> OP keep this in mind. There are fine resources available for learning
>> the principles and theory of OOP; one simply has to remember that much
>> real-world code deviates substantially.
> 
> OOP is supposed to be imperative, so I do not see much point in that
> argument.

OOP isn't "supposed" to be imperative at all, it just happens that most
mainstream OO languages are. C++, Objective-C, Java etc, those are
imperative OO languages. But you can and do have languages that are
functional and use OO, even some that are logical and have elements of OO.

To the extent that OO != imperative I don't withdraw my use of the term
"imperative". But I really meant "procedural", and should have used that
across the board.

However, let's stick to the imperative OO languages here. My argument is
that a great deal of actual (non-teaching) Java code strays
substantially from best-practice OO, and is best characterized as
"procedural" and/or "structured" and/or "modular". It doesn't really
have those extra features that distinguish good OO code.

That is the main argument I am making. And it's about "what is", as a
caution to the OP, not a reflection on the best Java or even decent Java
that can be written by a programmer who is reasonably well-grounded in
proper OO. I am pointing out what we often see.

> How big a portion of Java code that is procedural will depend a
> bit on where you put the bar.
> 
> If we put the bar relative low:
>   procedural = all static methods
>   OOP = use of interfaces, private fields public methods
> then the majority of Java code is not procedural.
> 
> Arne
> 
That's a very low bar, and it's selected to make a lot of Java and C#
real-world code look good. By that criterion all those large instance
methods out there that gather in a multitude of behavior-anemic objects
and perform algorithms on them are OOP. Well, of course they are
technically OOP.

What's the most classic "procedure" that Java has? The "main" method in
a main class. That's even one by your definition. Often what people do
in "main" is call the constructor of the main class, and invoke an
instance method on it that is the top-level "procedure". Not too much
really OO-like about that at all.

Let's consider Java EE. No small number of web apps have a fat "service"
or "application" layer that teems with procedural code. Session beans
and managed beans are loaded with large methods that, despite being
instance methods, are "procedures" that assemble a variety of
data-holder objects (not really interesting domain objects at all, not
by classic domain/model design they're not) and invoke logic on those
objects in an algorithmic way: mostly logic that ought to have been in
the "domain" objects. Even where some of the "procedural" code has been
subdivided to make it appear more OO-like, and is parcelled out to
"domain" objects to make them look better, it's awkward and forced.

Your definition would have it that all the instance code in this latter
category is non-procedural. Again, _technically_ it's OO. But that's
really stretching it.

I can almost hear Lew chiming in. To forestall that, I'll reiterate, I'm
pointing out to the OP that when inspecting _real_ Java that he should
be careful about what's good OO and what is merely *technically* OO.

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

[toc] | [prev] | [next] | [standalone]

#13632

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
 
> However, let's stick to the imperative OO languages here. My argument is
> that a great deal of actual (non-teaching) Java code strays
> substantially from best-practice OO, and is best characterized as
> "procedural" and/or "structured" and/or "modular". It doesn't really
> have those extra features that distinguish good OO code.

To be heretical, that's not neccessarily a bad thing. To a certain
extent, modern best practices have moved a little back from the idea
of "pure" or classical OO, with dictums such as "program against
interfaces, not classes" and "prefer composition over inheritance."

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#13642

Arved Sandstrom wrote:
> I can almost hear Lew chiming in. To forestall that, I'll reiterate, I'm
> pointing out to the OP that when inspecting _real_ Java that he should
> be careful about what's good OO and what is merely *technically* OO.

Far be it from me to disappoint my fans.

Arved's right, in that by a distinguishing definition of object-oriented. that is, one that sets it apart from "pre-"object-oriented styles, much Java code in the real world is not OO. The trivial definition, Arved's “merely *technically* OO”, doesn't much help one distinguish not very OO from very OO.

The question is, "So what?" 

So, "OO" shouldn't be a religion, but a measuring stick to help evaluate code quality. What we're really after here are best practices to organize code so that it's bug free, provably correct, inexpensively maintainable and magically satisfying to the customer. Taken together, such practices result in something arguably "object oriented" irrespective of source language.

But your object orientation is only ever as good as your analysis, and your implementation strategy to reduce state coupling and cogent modeling of the problem domain.

Same as procedural code that way.

So avoid the sorts of sins Arved described ("God classes", spaghetti code disguised as methods and so on), be aware of the valid (non-buzzwordy) virtues of OO, or generally of good code, and cast a jaundiced eye on real-world code and pedagogical examples alike.

Thanks for making the distinction, Arved.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13643

Lew wrote:
> But your object orientation is only ever as good as your analysis, and your implementation 
>  strategy to reduce state coupling and cogent modeling of the problem domain.

er, reduce coupling and *improve* cogent modeling. (Abashed grin)

[toc] | [prev] | [next] | [standalone]

#13647

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:

(snip, someone wrote)
>>> the principles and theory of OOP; one simply has to remember 
>>> that much real-world code deviates substantially.
 
>> OOP is supposed to be imperative, so I do not see much 
>> point in that argument.

> OOP isn't "supposed" to be imperative at all, it just happens that most
> mainstream OO languages are. C++, Objective-C, Java etc, those are
> imperative OO languages. But you can and do have languages that are
> functional and use OO, even some that are logical and have elements of OO.

But also, I believe, that there is an appropriate amount of OO-ness.

Especially for computationally intensive algorithms, the inner loops
should avoid creation of objects. Like just about everything, OO
can be over done.

> To the extent that OO != imperative I don't withdraw my use of the term
> "imperative". But I really meant "procedural", and should have used that
> across the board.

> However, let's stick to the imperative OO languages here. My argument is
> that a great deal of actual (non-teaching) Java code strays
> substantially from best-practice OO, and is best characterized as
> "procedural" and/or "structured" and/or "modular". It doesn't really
> have those extra features that distinguish good OO code.

Well, first of all, as I understand it the big advantage of OO is
readability. But even so, too much of a good thing isn't always good.
If something is more readable in procedural form, then do it that way!

There are procedures (usually in non-OO languages) that are thousands,
maybe tens of thousands of lines long. But there is a size that is
easily understood by a good programmer, maybe in the 100 line range,
and one shouldn't necessarily get smaller than that, just for OO sake.

Now, the other reason for OO is for extensibility, and sometimes
that will require an object where it otherwise might not be needed.

> That is the main argument I am making. And it's about "what is", as a
> caution to the OP, not a reflection on the best Java or even decent Java
> that can be written by a programmer who is reasonably well-grounded in
> proper OO. I am pointing out what we often see.

-- glen

[toc] | [prev] | [next] | [standalone]

#13649

On Wed, 18 Apr 2012 07:11:56 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

[snip]

>However, let's stick to the imperative OO languages here. My argument is
>that a great deal of actual (non-teaching) Java code strays
>substantially from best-practice OO, and is best characterized as
>"procedural" and/or "structured" and/or "modular". It doesn't really
>have those extra features that distinguish good OO code.

     "Look, kitty!  Pigeons!"  [toss]

     All methods are procedural.  The big deal about OO is how they
are called.

     OO can be very useful.  It can also lead to horrible clutter.
Just because I have OO in my arsenal does not mean that I have to use
it.  (The same thing applies to any tool.  Sometimes, it is a good
idea to use the tool, and sometime, something else is more
appropriate.)

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13993

On 4/18/2012 6:11 AM, Arved Sandstrom wrote:
> On 12-04-17 11:06 PM, Arne Vajhøj wrote:
>> On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
>>> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>>>> markspace<-@.>   wrote:
>>>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>>> languages, although I have done some work with a couple of
>>>>>> object-oriented ones.
>>>>
>>>>>> Which book would you recommend that I read to learn Java? Obviously, I
>>>>>> don't want to read a beginning programming book, nor do I want to
>>>>>> study
>>>>>> one which presupposes I know something about Java or a lot about OO
>>>>>> concepts.
>>>>
>>>> You can do procedural programming in Java. You might find it easier
>>>> to start that way, to get used to Java, and then learn the OO stuff.
>>>
>>> I suspect that a cold, hard analysis of all Java code written in the
>>> past 15 years would show that the large majority of it _is_ procedural.
>>>
>>> Fact is, Java and Objective-C and C++, to name a few OOP languages, are
>>> generally used to write substantially imperative code, where procedures
>>> appear as object methods. We may as well not ignore that, it's what most
>>> OO programmers do.
>>>
>>> Having said that, the advantage of objects and OOP shouldn't be
>>> discounted. We simply shouldn't pretend that modern OOP isn't still
>>> largely imperative/procedural code. If we advise the OP to learn proper
>>> OO - and I certainly do - the fact is that in his studies he's going to
>>> come across a stupendous amount of imperative Java. I recommend that the
>>> OP keep this in mind. There are fine resources available for learning
>>> the principles and theory of OOP; one simply has to remember that much
>>> real-world code deviates substantially.
>>
>> OOP is supposed to be imperative, so I do not see much point in that
>> argument.
>
> OOP isn't "supposed" to be imperative at all, it just happens that most
> mainstream OO languages are. C++, Objective-C, Java etc, those are
> imperative OO languages. But you can and do have languages that are
> functional and use OO, even some that are logical and have elements of OO.
>
> To the extent that OO != imperative I don't withdraw my use of the term
> "imperative". But I really meant "procedural", and should have used that
> across the board.
>
> However, let's stick to the imperative OO languages here. My argument is
> that a great deal of actual (non-teaching) Java code strays
> substantially from best-practice OO, and is best characterized as
> "procedural" and/or "structured" and/or "modular". It doesn't really
> have those extra features that distinguish good OO code.
>
> That is the main argument I am making. And it's about "what is", as a
> caution to the OP, not a reflection on the best Java or even decent Java
> that can be written by a programmer who is reasonably well-grounded in
> proper OO. I am pointing out what we often see.
>
>> How big a portion of Java code that is procedural will depend a
>> bit on where you put the bar.
>>
>> If we put the bar relative low:
>>    procedural = all static methods
>>    OOP = use of interfaces, private fields public methods
>> then the majority of Java code is not procedural.
>>
> That's a very low bar, and it's selected to make a lot of Java and C#
> real-world code look good. By that criterion all those large instance
> methods out there that gather in a multitude of behavior-anemic objects
> and perform algorithms on them are OOP. Well, of course they are
> technically OOP.
>
> What's the most classic "procedure" that Java has? The "main" method in
> a main class. That's even one by your definition. Often what people do
> in "main" is call the constructor of the main class, and invoke an
> instance method on it that is the top-level "procedure". Not too much
> really OO-like about that at all.
>
> Let's consider Java EE. No small number of web apps have a fat "service"
> or "application" layer that teems with procedural code. Session beans
> and managed beans are loaded with large methods that, despite being
> instance methods, are "procedures" that assemble a variety of
> data-holder objects (not really interesting domain objects at all, not
> by classic domain/model design they're not) and invoke logic on those
> objects in an algorithmic way: mostly logic that ought to have been in
> the "domain" objects. Even where some of the "procedural" code has been
> subdivided to make it appear more OO-like, and is parcelled out to
> "domain" objects to make them look better, it's awkward and forced.
>
> Your definition would have it that all the instance code in this latter
> category is non-procedural. Again, _technically_ it's OO. But that's
> really stretching it.

I wrote:
    procedural = all static methods
    OOP = use of interfaces, private fields public methods

It seems as if you are mostly arguing based on:
    procedural = some static methods

I don't think the presence of some static methods is anti-OO.
Several patterns from the GoF book uses static methods.

And I do not agree with the service methods plus data classes
not being OOP argument either.

Back in the 90's good OOP was rich classes with both methods
and data.

Today good OOP is more focused on the encapsulation aspects
(which was my second bullet point).

The 90's good OOP is now called "rich domain model".

One of the main drivers behind the change IMHO is that it became
clear that not everything was a good fit for traditional model. There
are simply needs for different focus on data versus method: some
classes are method heavy, some classes are a more even mix
and some classes are data heavy.

Encapsulation is used in almost all Java EE apps, because
Java EE is designed over these concepts and so are much of
the supplementary stuff like Hibernate (non JPA API),
Spring etc..

Arne

[toc] | [prev] | [next] | [standalone]

#14020

On 12-04-28 11:11 PM, Arne Vajhøj wrote:
> On 4/18/2012 6:11 AM, Arved Sandstrom wrote:
>> On 12-04-17 11:06 PM, Arne Vajhøj wrote:
>>> On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
>>>> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>>>>> markspace<-@.>   wrote:
>>>>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>>>> languages, although I have done some work with a couple of
>>>>>>> object-oriented ones.
>>>>>
>>>>>>> Which book would you recommend that I read to learn Java?
>>>>>>> Obviously, I
>>>>>>> don't want to read a beginning programming book, nor do I want to
>>>>>>> study
>>>>>>> one which presupposes I know something about Java or a lot about OO
>>>>>>> concepts.
>>>>>
>>>>> You can do procedural programming in Java. You might find it easier
>>>>> to start that way, to get used to Java, and then learn the OO stuff.
>>>>
>>>> I suspect that a cold, hard analysis of all Java code written in the
>>>> past 15 years would show that the large majority of it _is_ procedural.
>>>>
>>>> Fact is, Java and Objective-C and C++, to name a few OOP languages, are
>>>> generally used to write substantially imperative code, where procedures
>>>> appear as object methods. We may as well not ignore that, it's what
>>>> most
>>>> OO programmers do.
>>>>
>>>> Having said that, the advantage of objects and OOP shouldn't be
>>>> discounted. We simply shouldn't pretend that modern OOP isn't still
>>>> largely imperative/procedural code. If we advise the OP to learn proper
>>>> OO - and I certainly do - the fact is that in his studies he's going to
>>>> come across a stupendous amount of imperative Java. I recommend that
>>>> the
>>>> OP keep this in mind. There are fine resources available for learning
>>>> the principles and theory of OOP; one simply has to remember that much
>>>> real-world code deviates substantially.
>>>
>>> OOP is supposed to be imperative, so I do not see much point in that
>>> argument.
>>
>> OOP isn't "supposed" to be imperative at all, it just happens that most
>> mainstream OO languages are. C++, Objective-C, Java etc, those are
>> imperative OO languages. But you can and do have languages that are
>> functional and use OO, even some that are logical and have elements of
>> OO.
>>
>> To the extent that OO != imperative I don't withdraw my use of the term
>> "imperative". But I really meant "procedural", and should have used that
>> across the board.
>>
>> However, let's stick to the imperative OO languages here. My argument is
>> that a great deal of actual (non-teaching) Java code strays
>> substantially from best-practice OO, and is best characterized as
>> "procedural" and/or "structured" and/or "modular". It doesn't really
>> have those extra features that distinguish good OO code.
>>
>> That is the main argument I am making. And it's about "what is", as a
>> caution to the OP, not a reflection on the best Java or even decent Java
>> that can be written by a programmer who is reasonably well-grounded in
>> proper OO. I am pointing out what we often see.
>>
>>> How big a portion of Java code that is procedural will depend a
>>> bit on where you put the bar.
>>>
>>> If we put the bar relative low:
>>>    procedural = all static methods
>>>    OOP = use of interfaces, private fields public methods
>>> then the majority of Java code is not procedural.
>>>
>> That's a very low bar, and it's selected to make a lot of Java and C#
>> real-world code look good. By that criterion all those large instance
>> methods out there that gather in a multitude of behavior-anemic objects
>> and perform algorithms on them are OOP. Well, of course they are
>> technically OOP.
>>
>> What's the most classic "procedure" that Java has? The "main" method in
>> a main class. That's even one by your definition. Often what people do
>> in "main" is call the constructor of the main class, and invoke an
>> instance method on it that is the top-level "procedure". Not too much
>> really OO-like about that at all.
>>
>> Let's consider Java EE. No small number of web apps have a fat "service"
>> or "application" layer that teems with procedural code. Session beans
>> and managed beans are loaded with large methods that, despite being
>> instance methods, are "procedures" that assemble a variety of
>> data-holder objects (not really interesting domain objects at all, not
>> by classic domain/model design they're not) and invoke logic on those
>> objects in an algorithmic way: mostly logic that ought to have been in
>> the "domain" objects. Even where some of the "procedural" code has been
>> subdivided to make it appear more OO-like, and is parcelled out to
>> "domain" objects to make them look better, it's awkward and forced.
>>
>> Your definition would have it that all the instance code in this latter
>> category is non-procedural. Again, _technically_ it's OO. But that's
>> really stretching it.
> 
> I wrote:
>    procedural = all static methods
>    OOP = use of interfaces, private fields public methods
> 
> It seems as if you are mostly arguing based on:
>    procedural = some static methods
> 
> I don't think the presence of some static methods is anti-OO.
> Several patterns from the GoF book uses static methods.

You're pushing me too far over to one side when you characterize my
arguments. So far I've said little about static methods - I've been
noting the misuse of instance methods. I've focused deliberately on
instance methods because it is easier to disguise their misuse.

As far as static methods go, I don't think the use of *some* static
methods is bad either. They are inherently procedural, however. You
acknowledged that to some degree when you equated 'procedural = all
static'. I happen to think that the bar should be lower, that the more
of your code that you've jammed into static methods the more procedural
your code has become. There's no 0/100 black/white here.

I prefer static methods that are non-business-logic implementation
details, if you've got to use them at all. Like static factory methods.

> And I do not agree with the service methods plus data classes
> not being OOP argument either.

It's OOP. It's _technically_ OOP. More discussion below.

> Back in the 90's good OOP was rich classes with both methods
> and data.

Not always "good" OOP. Let's just call that "1990's OOP" or "1990's
accepted OOP".

> Today good OOP is more focused on the encapsulation aspects
> (which was my second bullet point).
> 
> The 90's good OOP is now called "rich domain model".
> 
> One of the main drivers behind the change IMHO is that it became
> clear that not everything was a good fit for traditional model. There
> are simply needs for different focus on data versus method: some
> classes are method heavy, some classes are a more even mix
> and some classes are data heavy.

That's exactly right: it became clear that the "emergent" premise behind
the rich domain model typically failed. People invariably had a
difficult time deciding where to put all their logic, because much of it
did not neatly belong to any one domain class. That led either to
abstract and dubious domain classes for the purpose of holding methods
that had no better home, or drove that change you referred to above (and
which I've criticized): creating lots of service classes in an
application layer, where this difficult-to-place logic gets put as
instance methods.

As a short-term response to the flaws inherent in the rich domain model
I have no serious problems with that change. A great deal of logic _is_
procedural, and you should code it up that way. But let's not call it
OO. My argument is just that, that a lot of Java code is procedural. I'm
not saying it's awful. When I previously used language like "ought to
have been", I'm saying that in reference to what you'd strive for with
classic, rich domain model OO.

This is my point exactly: that this change to lots of procedural, for
basically good reasons, has happened in Java (and other class-oriented
languages like C#). What is a problem is that people continue to insist
that this procedural code isn't.

I've mentioned DCI numerous times before: it is precisely an effort to
put some formalism and structure into how one deals with this
algorithmic/procedural code in an OO environment.

> Encapsulation is used in almost all Java EE apps, because
> Java EE is designed over these concepts and so are much of
> the supplementary stuff like Hibernate (non JPA API),
> Spring etc..
> 
> Arne
> 
Encapsulation is great. I don't care if one class is basically a struct
(Java Bean) and another is a domain class loaded with behaviour - they
all have their place. Encapsulation enters into all of that.

However, the argument here is about where a lot of the procedural logic
goes. The attempt to keep it all in domain classes failed a long time
ago. People have adjusted, often quite well. 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.

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

[toc] | [prev] | [next] | [standalone]

#14035

Arved Sandstrom wrote:
> Arne Vajhøj wrote:
>> Arved Sandstrom wrote:
>>> Arne Vajhøj wrote:
>>>> Arved Sandstrom wrote:
>>>>> glen herrmannsfeldt wrote:
>>>>>> markspace wrote:
>>>>>>> Steve Graham wrote:
>>>>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>>>>> languages, although I have done some work with a couple of
>>>>>>>> object-oriented ones.


Superb point/counterpoint exchange, comrades, with many points on both sides.

... fast-forwarding ...

> However, the argument here is about where a lot of the procedural logic
> goes. The attempt to keep it all in domain classes failed a long time
> ago. People have adjusted, often quite well. 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.

Pretty good job of teasing apart the two questions of, "Is that 
object-oriented?" and, "Is that good code?".

Other discussions in this forum have called out the distinction between an 
"object" in a sense useful to computer programming and an "object" as it's 
usually taught to programmers. Classic pedagogical examples like "A Ford 
/is-a/ Car that /has-an/ Engine" do some harm to understanding what an object 
really is in a programming sense.

Part of the difficulty in the discussion here is to converge on a definition 
of "object-oriented". Some, amongst whom I will presume to number Arved, hold 
to a very rigid technical definition, fortunately devoid of value judgment, 
with the notion of degree of compliance to that definition. It's attractive, 
because his characterization allows an unambiguous statement like, "This 
program is 73% object oriented."

Except that orientation is by design an imperfect and teleological notion. I'd 
prefer a more, well, objective term such as "objectified", or 
"object-compliant". You can orient yourself to objects but still digress to 
what we've been pleased to call "procedural" code.

Regardless. The central message that emerges is that 100% object-compliant 
code is not necessarily a good thing and rarely if ever seen in Java code 
(that works). At less than 100%, a programmer still thinks in terms of objects 
(orients themself to them), but occasionally needs some function to stand as 
its own sort of object (what a first-class notion), or procedure, apart from 
the purity of a fantastic "object model", and strays from the object path to 
static methods and such.

And yet - and yet -

If it's good code, and I'm willing to bet sight unseen that both Arne and 
Arved write very good code, there will be attributes of encapsulation, 
inheritance, and polymorphism throughout, even to the static constructs. The 
mental model for class-level behavior in Java might still conceive in 
"object-oriented" terms that which Java itself cannot directly express. 
(Functional programmers: time to jump in with your functional-flavor of the 
month rant.)

Don't make "object-oriented" a religion. If it makes you more comfortable to 
reason Arved's way, and call what you do "73% object-oriented", or to go 
Arne's way and say, "Sure, it's object-oriented, static methods 
notwithstanding", or to frame it some other way, go for it. Just be ready to 
map your understanding to common terms when talking with others, and continue 
to write good code.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14041

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.

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.

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.

[toc] | [prev] | [next] | [standalone]

#14059

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web