Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Learning Java Date: Wed, 18 Apr 2012 10:19:08 -0700 (PDT) Organization: http://groups.google.com Lines: 36 Message-ID: <25044298.11.1334769548533.JavaMail.geo-discussion-forums@pbcvh6> References: <4f8e21b4$0$293$14726298@news.sunsite.dk> NNTP-Posting-Host: 69.28.149.29 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1334769549 1666 127.0.0.1 (18 Apr 2012 17:19:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 18 Apr 2012 17:19:09 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 Xref: csiph.com comp.lang.java.programmer:13642 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. t= hat is, one that sets it apart from "pre-"object-oriented styles, much Java= code in the real world is not OO. The trivial definition, Arved's =93merel= y *technically* OO=94, doesn't much help one distinguish not very OO from v= ery OO. The question is, "So what?"=20 So, "OO" shouldn't be a religion, but a measuring stick to help evaluate co= de quality. What we're really after here are best practices to organize cod= e so that it's bug free, provably correct, inexpensively maintainable and m= agically 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 your= implementation strategy to reduce state coupling and cogent modeling of th= e problem domain. Same as procedural code that way. So avoid the sorts of sins Arved described ("God classes", spaghetti code d= isguised as methods and so on), be aware of the valid (non-buzzwordy) virtu= es of OO, or generally of good code, and cast a jaundiced eye on real-world= code and pedagogical examples alike. Thanks for making the distinction, Arved. --=20 Lew