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

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

Re: Learning Java

Show all headers | View raw

On 12-05-05 07:17 PM, Arne Vajhøj wrote:
> On 4/29/2012 10:00 AM, Arved Sandstrom wrote:
>> 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.
> 
> My point is that it did not change to procedural - it changed
> to a different type of OO.
> 
> OO is not a synonym for a rich domain model.
> 
> http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts
> 

Believe me, I know. I experiment with Self a lot, have for a few years.
My first exposure to OOP - as in seriously thinking about it - was
actually Prograph about 20 years ago, followed by Smalltalk and C++ and
Perl 5 OOP shortly after. Add into that Javascript and Ruby and so
forth, and I think I have probably been more an object-oriented OO guy
rather than a class-oriented OO guy right from the gitgo. When you think
objects, even in a language like C# or Java that wants you to think of
class instances, you tend to not have a rich/anemic domain mindset in
the first place.

None of these languages really made me think about rich domain objects;
I didn't start reading about that until Java had been around for a
while...it seems like the OOP pundits wrote some of the more well-known
rich-domain model articles (like Fowler's article about anemic domain
models in 2003) after the evidence was starting to amass that rich
domain was actually problematic.

I won't say that I have written either predominantly rich or anemic
domain classes, I think over the past few decades it's been a mix as
required.

Fowler and his adherents, and the DDD people, would never have pushed
their ideas if there weren't a lot of folks who *never* bought into the
rich domain model in the first place. In other words, there have always
been a lot of OO programmers who write procedural.

> http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
> 
> does not seem to conflict with what you call procedural.
> 
> Arne

No, I don't think it does either. As you may have gathered from the
above, I'm very comfortable in a object-based OO environment as opposed
to a class-based OO environment, and I like the way Kay minimalizes what
is really essential.

I think of OO as being about objects - period - and to me an object is a
bundle of data that can do stuff to itself. That a great deal of teh
overall program code might be non-object, and simply call upon objects
when necessary, is not a concept I have an issue with.

AHS
-- 
Never interrupt your enemy when he is making a mistake.
--Napoleon

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web