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 don't think the presence of some static methods is anti-OO.
clear that not everything was a good fit for traditional model. There