Combating the ‘Object Crisis’

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.)

 

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.

All too often, organizations wishing to build sophisticated, distributed, Web-deployed applications using either Java 2 Enterprise Edition (J2EE) or Microsoft’s .NET technologies attempt to retool their software development staff in the Java or C# programming language by sending them to “traditional” language training classes. There is a fundamental flaw with the way in which Java and C# are approached by most courses, however: students are assumed to have a priori understanding of basic object concepts, and so such courses more often than not focus solely on language syntax.  The bottom line is that students come away from such training without any knowledge of how to structure a software application from the ground up to make the most of Java or C#’s object-oriented nature.

The upshot is that, time and again, I meet software developers – at my place of employment, at clients’ offices, at professional conferences, on college campuses – who have attempted to master the Java or C# language so as to build sophisticated J2EE or .NET applications, but who are lacking a basic understanding of what objects are all about, and more importantly, knowledge of how to structure a software application from the ground up to make the most of objects.

{mospagebreak title=The Importance of Being ‘Object Savvy’}

Imagine that you have been asked to build a house and that you know the basics of home construction. In fact, you are a world-renowned home builder whose services are in high demand! Your client tells you that all of the materials you will need for building this home are going to be delivered to you. On the day construction is to begin, a truck pulls up at the building site and unloads a large pile of strange, blue, star shaped blocks with holes in the middle. You are totally baffled. You have built countless homes using materials such as lumber, brick, and stone, and you know how to approach a building project using these familiar materials; but you haven’t got a clue about how to assemble a house using blue stars.

Barker

Scratching your head, you pull out a hammer and some nails and try to nail the blue stars together as if you were working with lumber, but the stars don’t fit together very well. You then try to fill in the gaps with the same mortar that you would use to adhere bricks to one another, but the mortar doesn’t stick to these blue stars very well. Because you are working under tight cost and schedule constraints for building this home for your client, however (and because you are too embarrassed to admit that you, as an ‘expert’ builder, don’t know how to work with these modern materials), you press on. Eventually, you wind up with something that looks (on the outside, at least) like a house.


 

Barker

Your client comes to inspect the work, and is terribly disappointed.  One of reasons he had selected blue stars as a construction material was that they are extremely energy efficient; but, because you have used nails and mortar to assemble the stars, they have lost a great deal of their inherent ability to insulate the home. To compensate, your client asks you to replace all of the windows in the home with triple pane thermal glass windows so that they will allow less heat to escape. You are panicking at this point! Swapping out the windows will take as long, if not longer, than it has taken to build the house in the first place, not to mention the cost of replacing stars that will be damaged in the renovation process. 

When you tell your customer this, he goes ballistic! Another reason that he selected blue stars as the construction material was because of their recognized flexibility and ease of accommodating design changes, but because of the ineffective way in which you assembled these stars, you are going to have to literally rip them apart and replace a great many of them.


Barker

This is, sad to say, the way many programmers wind up building an object-oriented (OO) application when they don’t have appropriate training in how to approach the project from the perspective of objects. Worse yet, the vast majority of would-be OO programmers are blissfully ignorant of the need to understand objects in order to program in an OO language. So, they take off programming with a language like Java or C# and wind up with a far from ideal result: a program which lacks flexibility when an inevitable ‘mid course correction’ occurs in terms of a change in the requirements specification, as when new functionality needs to be introduced after an application has been deployed.

{mospagebreak title=What Factors Have Contributed to this ‘Object Crisis’?}

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.

{mospagebreak title=Conquering the ‘Object Crisis’}

The object crisis is by no means insurmountable. Quite the contrary:  by observing a few basic guidelines for how best to retool with objects in general/Java or C# in particular, an individual or an organization can quickly be off to the right start:

  1. Invest in object training before Java or C# training: it’s like learning how to hold a golf club properly before strategizing how to play a particular golf course. But, choose wisely: ensure that whatever object training you select does not teach objects in isolation but instead illustrates how one bridges the gap from UML models into Java or C# code.

  2. Craft your own Java or C# code using a bare-bones IDE (or a simple text editor) so as to master the concepts of the language before relying on a drag-and-drop GUI-builder to churn out code automatically. This way, you’ll ensure that an application is sound to its very core with respect to its object structure.

  3. Engage an object mentor who is also Java- or C#-proficient to work with a fledgling Java or C# team throughout the project lifecycle.

  4. Tackle a reasonably small project for starters — don’t attempt to conquer a mission-critical enterprise level application as your first application. And, ideally, cut your teeth on an in-house project versus a project-for-hire for a key client.

  5. If you are responsible for managing such a project, realize that there’ll be a hefty learning curve for first-time .NET or J2EE developers, and factor that into the project schedule. Not only must they conquer the language of choice, they must also come up to speed on: (a) the web programming paradigm, (b) the myriad of .NET or J2EE component technologies – each with its own particular conceptual hurdles and challenges.

The object paradigm is intuitive and powerful … nonetheless, mastery of objects doesn’t happen automatically simply by virtue of learning Java or C# syntax.  An up-front investment in learning objects properly will be repaid numerous times over in terms of the quality, maintainability, and robustness of the J2EE or .NET applications that ensue.


 

[gp-comments width="770" linklove="off" ]

chat