Jacquie Barker is right on the money. Many Java books look like reconfigured Pascal or C books, with new material added for Java. Most wait until you wade through hundreds of pages of material until you see anything about interfaces, inheritance and polymorphism.

I am in charge of the new CS program at the North Carolina School of Science and Mathematics. We will bulldoze the old curriculum this year and begin Java using an "objects-first" approach. Before learning Java, our student will first be exposed to Python.

A noted exponent of the objects-first approach is the CS program at Rice University. I attended their workshop this summer and have seen how the interrelationship between objects can handled in an accessible way. Their IDE, DrJava is suited to this purpose. It provides a "language level" feature to insulate the beginner from a lot of syntactic complexity, so the beginner can focus on creating small, coherent classes that work together to do a job.

This will be an exciting year at Science and Math!

Tony, the issue that you are describing is not an uncommon one, because most people aren't taught J2EE component technologies (JSPs, servlets, EJBs, etc.) properly; hence, they "sling" code (including HTML, JavaScript, and Java) to build thin-client Java apps, but wind up with a tangled mess when it comes to extensibility and maintainability. Hence, the elegance of objects seems to be lost in the shuffle, which could easily lead one to believe that J2EE isn't object-oriented. However, if properly architected, J2EE solutions EMBRACE objects, whether those objects are simple Java classes, known as "Java Beans", or industrial strength ENTERPRISE Java Beans (EJBs). JSPs and servlets become the "glue", or framework, for instantiating and orchestrating the behaviors of such domain, or business, objects.

I have just finished developing a new course entitled "Deploying Java Objects" as a sequel to my book, Beginning Java Objects; my new D.J.O. course covers how best to assemble thin-client Java applications to harness the power of objects, in the same way that my B.J.O. book handled the subject with respect to Swing desktop applications. Please see my website, objectstart.com, for details on a soon to be released self-study version of this new course.

Best Regards,

Jacquie

The problem is not merely with the devleopers, and is broader than one might first guess. More than two years ago I approached JDJ, Java Report, Java Pro, and JavaWorld with a proposal to write a series of articles under the banner "Fundamental OO, Perspectives on Java Design and Implementation". JDJ and Java Pro said no. I also proposed the topic for presentations for industry conferences; again, no. Fortunately (for me, anyway), JavaWorld and Java Report did accept my idea, and I've written a number of article for them. I'm also giving a couple of presentations on the lastest Java Jam (part of the Geek Cruises) next week.

The reason for the rejections? The magazines and conferences were more intersted in publishing and pushing the promises of the lastest buzzwords, encouraging Java developers toward a fomented rush to "master" the lastest API. They reasoned no one needed or cared about why something works, just how.

Fortunately (for all of us) this may slowly change. Jacquie's book, Joshua Bloch's "Effective Java", and others are promising to bring attention back to the power of fundamental understanding and first principles. I argue that a fundamental understanding of OO is requisite for building solid solutions, as opposed to just a solution.

And in parting, realize this is not a new problem or issue. Consider this gem from David Parnas (quoted from Fred Brooks' "The Mythical Man-Month", ):

"Instead of teaching people that O-O is a type of design, and giving them
design principles, people have taught that O-O is the use of a particular
tool. We can write good or bad programs with any tool. Unless we teach
people how to design, the languages matter very little. The result is that
people do bad designs with these languages and get very little value from
them."

-wcpr-

Jacquie,
I enjoyed your article, and agree with you, however, I was hoping for some more concrete examples of learning about Object Training. Could you suggest any books or training programs?
Thanks,
Alan

When I wrote my book Understanding Object-Oriented Software Engineering 1996 I thought that the object paradigm was something natural to our mind. (That is, something we were born with). Perhaps that is true but now I know that the object paradigm is definitely NOT something the typical software developer is happy with. I think this is one of the major reasons to why Smalltalk never became THE object-oriented programming language for example. Unfortunately most companies look for that "quick fix" but there just is no such quick fix. What can then be done? In my book I warned that there would be those that would never learn to use the object paradigm. That is, those that cannot learn the object paradigm should not work with code where understanding that paradigm is important. Secondly, we must give people time to learn the object paradigm before they start working (for example) with java. This will take time for all but those few natural talents that do have this paradigm already "set in their brains". The best way to start this learning is still by using Smalltalk! Other advice such as having an experienced object mentor also applies of course. Finally, perhaps the most important advice is to be aware of the problem and together with the object mentor plan how an application shall be developed (team members, development phases, application architecture etc)

[Understanding Object-Oriented Software Engineering, IEEE 1996; based on investigations and experience from Sweden 1990-1995; Now out of print]

Absolutely right, Jacquie. However, I wonder if there is another factor. New Java technologies appear to be springing up all of the time. I'm pretty much a core Java developer but stuff like EJB (before 2.0), servlets, JSF, struts and the like, don't seem to be very object oriented. Maybe getting those new Java developers to think objects will be even more difficult than you think.