This Book s Scope

This Book's Scope

As the title suggests, this book is about the object-oriented (OO) thought process. Obviously, choosing the theme and title of the book are important decisions; however, these decisions were not all that simple. Numerous books deal with one level or another of object orientation. Several popular books deal with topics including OO analysis, OO design, OO programming, design patterns, OO databases, the Unified Modeling Language (UML), various OO programming languages, and many other topics related to OO programming.

However, while poring over all of these books, many people forget that each one of these topics are built on a single foundation: how you think in OO ways. It is unfortunate, but often software professionals dive into these books without taking the appropriate time and effort to really understand the concepts in them.

I contend that learning OO concepts is not accomplished by learning a specific development method or a set of tools. Doing things in an OO manner is, simply put, a way of thinking. This book is all about the OO thought process.

Separating the methods and tools from the OO thought process is not easy. Many people are introduced to OO concepts via one of these methods or tools. Many C programmers were first introduced to object orientation by migrating directly to C++ ”before they were even remotely exposed to OO concepts. Some software professionals were first introduced to object orientation by presentations that included object models using UML ”again, before they were even exposed directly to OO concepts.

It is important to understand the significant difference between learning OO concepts and using the methods and tools that support the paradigm. In his article "What the UML Is ”and Isn't," Craig Larman states

Unfortunately, in the context of software engineering and the UML diagramming language, acquiring the skills to read and write UML notation seems to sometimes be equated with skill in object-oriented analysis and design. Of course, this is not so, and the latter is much more important than the former. Therefore, I recommend seeking education and educational materials in which intellectual skill in object-oriented analysis and design is paramount rather than UML notation or the use of a case tool.

Although learning a modeling language is an important step, it is much more important to learn OO skills first. Learning UML before OO concepts is similar to learning how to read an electrical diagram without first knowing anything about electricity.

The same problem occurs with programming languages. As stated earlier, many C programmers moved into the realm of object orientation by migrating to C++ before being directly exposed to OO concepts. Many times developers who claim to be C++ programmers are simply C programmers using C++ compilers.

This problem is even more of an issue now that object-oriented languages like Java, C# .NET, Visual Basic .NET, and so on have become so popular. There are many Visual Basic programmers who now must make the leap to Visual Basic .NET. Likewise, many C++ programmers, who might not be conforming to strict OO practices, are being asked to migrate to Java or C#, where they have no choice but to think in OO ways.

Early versions of Visual Basic are not OO. C is not OO, and C++ was developed to be backward compatible with C. Because of this, it is quite possible to use a C++ compiler writing only C syntax while forsaking all of C++'s OO features. Even worse , a programmer can use just enough OO features to make a program incomprehensible to OO and non-OO programmers alike.

Thus, it is of vital importance that while you're on the road to OO development, you first learn the fundamental OO concepts. Resist the temptation to jump directly into a programming language (such as C++, C# or Java) or a modeling language (such as UML), and take the time to learn the object-oriented thought process.

This book is a concepts book intended to introduce programmers to object-oriented technologies. One of these audiences is, of course, structured programmers making the leap to O-O. Thus, I have included some material that is, in fact, a bridge between structured and object-oriented technologies. Chapter 6 is a good example of this approach - I have included techniques that will be familiar to structured programmers. It is important to understand that Object-oriented and structured practices are not mutually exclusive. Structured techniques are used throughout O-O designs (just consider a for loop or if statement).

In my first class in Smalltalk in the late 1980s, the instructor told the class that the new OO paradigm was a totally new way of thinking. He went on to say that although all of us were most likely very good programmers, about 10% “20% of us would never really grasp the OO way of doing things. If this statement is indeed true, it is most likely because some people never really take the time to make the paradigm shift and learn the underlying OO concepts.