Re: Learning Java
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