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

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

Re: Learning Java

Show all headers | View raw

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

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