Learning Java

Discussion in 'Java' started by Steve Graham, Apr 17, 2012.

  1. Steve Graham

    Steve Graham Guest

    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
    Steve Graham, Apr 17, 2012
    #1
    1. Advertising

  2. Steve Graham

    markspace Guest

    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.
    markspace, Apr 17, 2012
    #2
    1. Advertising

  3. 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
    glen herrmannsfeldt, Apr 17, 2012
    #3
  4. Steve Graham

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Apr 18, 2012
    #4
  5. Steve Graham

    Arne Vajhøj Guest

    On 4/17/2012 5: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.


    I think you need a book like this one:

    http://www.wrox.com/WileyCDA/WroxTitle/Professional-Java-JDK-6-Edition.productCd-0471777102.html

    Note that I do not know the specific book, but other of
    Wrox'es "Professional Xxxxx" are good.

    Arne
    Arne Vajhøj, Apr 18, 2012
    #5
  6. Steve Graham

    markspace Guest

    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.)
    markspace, Apr 18, 2012
    #6
  7. 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
    Arved Sandstrom, Apr 18, 2012
    #7
  8. Steve Graham

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Apr 18, 2012
    #8
  9. 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
    glen herrmannsfeldt, Apr 18, 2012
    #9
  10. Steve Graham

    Stefan Ram Guest

    glen herrmannsfeldt <> writes:
    >Java is much like C


    Here is an example C code (an untested library)
    to be translated to Java:

    #include <stdio.h>

    int open
    ( const char * const path,
    const char * const mode,
    double( *continuation )( FILE *, void * ),
    double( *error )( int, int ),
    void * data )
    { FILE * const file = fopen( path, mode );
    int result = 0; int status;
    if( !file )result |= 1; else
    { if( status = continuation( file, data ))result |= 2;
    if( fclose( file ))result |= 4; }
    if( result )
    { if( error( result, status ))result |= 8; }
    return result; }
    Stefan Ram, Apr 18, 2012
    #10
  11. 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
    Arved Sandstrom, Apr 18, 2012
    #11
  12. Steve Graham

    Lew Guest

    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 Javacode 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 yourimplementation 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-worldcode and pedagogical examples alike.

    Thanks for making the distinction, Arved.

    --
    Lew
    Lew, Apr 18, 2012
    #12
  13. Steve Graham

    Lew Guest

    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)
    Lew, Apr 18, 2012
    #13
  14. Arved Sandstrom <> 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
    glen herrmannsfeldt, Apr 18, 2012
    #14
  15. On Wed, 18 Apr 2012 07:11:56 -0300, Arved Sandstrom
    <> 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
    Gene Wirchenko, Apr 18, 2012
    #15
  16. On 17/04/2012 22:50, 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'd strongly advise against this. An awful lot of Java programming
    consists of using the standard libraries. To do so effectively I really
    think you have to start by learning Java OO.

    There is an O'Reilly book called "Learning Java". I found it helpful.
    The online resources referred to by others are also good for initial
    learning. The other books suggested (Effective Java, Java Concurrency)
    are very good but I'd suggest not starting with them (don't delay
    reading them too long either)

    Just my ¤0.02 worth.

    --
    RGB
    RedGrittyBrick, Apr 19, 2012
    #16
  17. Steve Graham

    Roedy Green Guest

    On Tue, 17 Apr 2012 15:03:07 -0600, Steve Graham
    <> wrote, quoted or indirectly quoted someone who
    said :

    >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.


    see http://mindprod.com/jgloss/gettingstarted.html
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    When you were a child, if you did your own experiment
    to see if it was better to put to cocoa into your cup first
    or the hot milk first, then you likely have the programmer gene..
    Roedy Green, Apr 27, 2012
    #17
  18. Steve Graham

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Apr 29, 2012
    #18
  19. Steve Graham

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Apr 29, 2012
    #19
  20. 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
    Arved Sandstrom, Apr 29, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hal Vaughan
    Replies:
    7
    Views:
    472
  2. Hayak
    Replies:
    1
    Views:
    469
    BigSargeone
    Apr 17, 2007
  3. Begin Learning Java
    Replies:
    5
    Views:
    607
    Arne Vajhøj
    Mar 17, 2010
  4. Lew
    Replies:
    0
    Views:
    395
  5. Andrey Popp

    [I'm learning C]: Learning to use ucontext

    Andrey Popp, Jan 29, 2012, in forum: C Programming
    Replies:
    5
    Views:
    705
    Keith Thompson
    Jan 31, 2012
Loading...

Share This Page