How do I master it?

It takes a three-pronged strategy to master the OO paradigm for solving actual problems involving large and complex systems. You must, of course, learn the syntax specific to the languages. Clearly, without a working level familiarity with all the major constructs of a language, you may not be able to bring to bear the most effective tools on a problem. This, however, does not mean that you must memorize all of the syntax. For example, it would be impossible to commit to memory all of the different Java classes and the attributes and the functions associated with each of the classes. Fortunately, it is not necessary to do so in this age of web-based documentation. A standard approach to Java programming is to display in one window the extremely well-organized on-line Java documentation while you are constructing your own program in another window.

In addition to the syntax, you must master for each language the concepts of encapsulation, inheritance, and polymorphism, as these three concepts form the cornerstones of a truly OO language. How each concept works varies in subtle ways from language to language. For example, C++ permits multiple inheritance which gives a programmer certain freedoms, but with an increased risk of writing buggy code. On the other hand, Java forbids multiple inheritance in the sense permitted by C++, but allows for a class to inherit from any number of interfaces. Similarly, the access modifiers that allow you to encapsulate information in a class with different levels of access work slightly differently in C++ and Java. Additionally, Java has the concept of a package that has a bearing on access control—a concept that does not exist in C++. Polymorphism allows a subclass type to be treated like a superclass type. Although it works essentially the same in all major OO languages, the manner in which it is invoked can place important constraints on programming. In C++, for example, polymorphism can only be invoked through pointers, a fact that can have a large bearing on how you might refer to an object in a program.

The last of the three-pronged strategy deals with learning OO design. As with all design activity, there is a certain mystique associated with it. This is not surprising, because it would be impossible to enunciate the design principles that would span all possible problems, those already solved and those yet to be solved. Much of learning how to design an OO solution to a large and complex problem is a matter of experience, aided perhaps by examining good OO code written by other people. Nonetheless, the accumulated wisdom over the years now dictates the following approach to the development of expertise in OO design: (1) mastering a "meta" language, such as the Unified Modeling Language (UML), that allows you to express your design visually at a conceptual level; and (2) learning the design patterns, these being template solutions to a host of subproblems likely to be encountered during the evolution of an OO program. This book contains an abbreviated introduction to UML in Chapter 14. Regarding design patterns, there is no specific chapter devoted to it, although the example code presented includes the implementation of some of the patterns. For a reader wanting to pursue more deeply both UML and the topic of design patterns, there are excellent books available on both [7, 13, 20, 21].