What Factors Have Contributed to this 'Object Crisis'? - Java
The phenomenal success of object-oriented languages such as Java and C# as enablers of enterprise-wide, Web-deployed applications has compelled countless numbers of organizations and individual professionals alike to seek proficiency with such language in recent years. Many of these are drawn like moths to a flame, however -- and in fact go “down in flames” -- because they are ill prepared to harness the power of an object-oriented programming language, due to a basic lack of understanding of object concepts. (Copyright 2004 by Jacquie Barker – all rights reserved. Reprinted with permission of the author. Excerpted in part from Beginning Java Objects: From Concepts to Code, by Jacquie Barker, ISBN 1590591461; published by Apress LP.)
Although the object paradigm has been embraced by the software engineering community at large for many years, there are still many professional software developers who are schooled only in procedural programming languages such as C, COBOL, BASIC, or Fortran. Many of these programmers are now looking to make the transition from procedural to object-oriented programming with Java or C#, but feel as though the object technology 'wave' has perhaps passed them by. Motivated by career survival, they are seeking a 'quick fix' -- a single book or course that can transform them into Java- or C#-proficient software engineers.
Meanwhile, organizations eager to harness the power of J2EE or .NET are attempting to retool their in-house programming staff, many of whom are senior procedural programmers, en masse in these technologies. Eager to do so in the quickest way possible, they fall prey to the notion that sending competent programmers -- especially C++ programmers, who are presumably already proficient with object-oriented programming (which is not necessarily the case, as we'll discuss in a moment) -- to Java/C# training will produce instant "Java/C# savvy". From there, they believe (incorrectly) that it's a short hop to training them in J2EE/.NET.
What such individuals or organizations often don't realize, however, is that:
Most Java or C# training does only a cursory job of explaining object concepts. After a perfunctory lesson on "What is an object? What is a class?", instructors usually dive into the details of language syntax without giving participants a big picture appreciation for the nature of objects. Topics key to harnessing the full power of a language like Java or C# - e.g., encapsulation, information hiding, object collaboration, overriding, polymorphism - are not taught in depth, but rather are merely touched upon in passing, if at all. Students go through the motions of writing code "snippets", but don't truly understand the rationale for what they are doing.
Conversely, most traditional object training emphasizes object modeling techniques and the Unified Modeling Language (UML) notation in particular, but does not advise students on how to bridge the gap from a UML object model to a working Java or C# application. Hence, upon completion of such training, students are able to produce respectable class diagrams that do justice to the requirements of an application, but cannot translate such object "blueprints" into code.
Many software engineers who adopted C++ as a core programming language were 'born again' C programmers who gravitated to C++ as a better C. Such programmers were not compelled to learn the object paradigm beyond a superficial level because they were able to successfully write procedural C++ code upon merely learning C++ language syntax; that is, they became C++ programmers, but not necessarily OO programmers. Despite many similarities in the syntax of these three languages, Java and C# are both arguably more true to the object paradigm than is C++: that is, Java and C# both provide fewer 'back doors' with which a programmer can escape the rigor of objects, as compared with C++. Those C++ programmers who never learned objects properly to begin with do not have a "leg up" on learning Java or C#, as management might hope they do, and hence organizations often underestimate what it will take to re-craft such programmers into capable OOPL developers.
The prevalence of drag and drop IDEs exacerbate the situation, because while such tools do indeed allow folks without object know-how to craft object oriented user interfaces, these UIs sit on top of a non-OO infrastructure. Like the Hollywood facade of a town in the Old West, an application built with such an IDE may appear to be object oriented, but scratch the surface and you'll see that that is where the appearance ends: there is a noticeable discontinuity between the OO front-end and a decidedly non-OO back-end.