Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe23.iad.POSTED!8ad76e89!not-for-mail From: Arved Sandstrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Learning Java References: <4f8e21b4$0$293$14726298@news.sunsite.dk> <4f9ca365$0$295$14726298@news.sunsite.dk> <4fa5a6e3$0$287$14726298@news.sunsite.dk> In-Reply-To: <4fa5a6e3$0$287$14726298@news.sunsite.dk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 236 Message-ID: <_Izpr.40349$mL3.23146@newsfe23.iad> X-Complaints-To: abuse@newsgroups-download.com NNTP-Posting-Date: Sun, 06 May 2012 18:49:30 UTC Organization: Public Usenet Newsgroup Access Date: Sun, 06 May 2012 15:49:29 -0300 X-Received-Bytes: 12346 Xref: csiph.com comp.lang.java.programmer:14341 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