Combating the ‘Object Crisis’ - What Factors Have Contributed to this 'Object Crisis'? (Page 3 of 4 ) 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.
Next: Conquering the 'Object Crisis' >>
More Java Articles
More By Jacquie Barker |
