The Object-Oriented Thought Process
By Matt Weisfeld
January 28, 2004
(From: http://www.developer.com/java/other/print.php/3304881)
Introduction
This is the first installment in a series of articles about The Object-Oriented Thought Process. The material used in these articles is excerpted from the second edition of my book of the same title.
Choosing the theme and title of a book, or a column, are important decisions. The choices made were not all that simple because there are a lot of very good books and articles on various object-oriented (OO) topics—including OO analysis, OO design, OO programming, design patterns, OO databases, the Unified Modeling Language (UML), various OO programming languages, and many other OO topics.
However, while pouring over all of these books, many people forget that every one of these topics is built on a single foundation: how you think in object-oriented ways. It is unfortunate, but often software professionals dive into these books without taking the appropriate time and effort to really understand the concepts behind 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 column is all about the object-oriented thought process.
Separating the development methods and tools from the OO thought process is not easy. Many people are introduced to OO concepts via one of these development 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. Often, 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 such as Java, C# .NET, and Visual Basic .NET 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 and use 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.
While taking my first Smalltalk class 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% to 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.
This Column's Scope
It should be obvious by now that I am a firm believer in becoming comfortable with the object-oriented thought process before jumping into a programming language or modeling language. These columns will be filled with examples of Java, C#, and VB .Net code as well as UML diagrams; however, you do not need to know Java, C#, and so forth or UML to really understand the concepts. After all I have said about learning the concepts first, why will there be so much code and so many UML diagrams? First, they are both great for illustrating OO concepts. Second, both are vital to the OO process and should be addressed at an introductory level. The key is not to focus on code or UML, but to use them as aids in the understanding of the underlying concepts.
I cannot state too strongly that this column will not teach coding syntax or UML, both of which can, and do, command separate books. It is my hope that this column will whet your appetite for other OO topics, such as OO analysis, object-oriented design, and OO programming.
Introduction to Object-Oriented Concepts
Although it might be a bit surprising, object-oriented software development has been around since the early 1960s. Although objects have become much more prevalent in today's software industry, a number of software shops have yet to venture into the OO arena. It is no secret that the software industry can be slow moving at times. It is also true that, when working systems are in place, there has to be a compelling reason to replace them. This has hindered the propagation of OO systems. There are a lot of non-OO legacy systems (that is, older systems that are already in place) that seem to be working just fine so why risk potential disaster by changing them? In most cases, you should not change them, at least not simply for the sake of change. There is nothing inherently wrong with systems written in nonOO code. However, brand-new development definitely warrants the consideration of using OO technologies.
Although there has been a steady and significant growth in OO development in the past 10 years, an entirely new venue has helped catapult it further into the mainstream. The emergence of the Web has opened a brand-new arena, where much of the software development is new and mostly unencumbered by legacy concerns. Even when there are legacy concerns, there is a trend to wrap the legacy systems in object wrappers.
Object Wrappers
Object wrappers are object-oriented code that includes structured code inside. For example, you can take a structured module and wrap it inside an object to make it look like an object.
Objects are slowly but surely making their way into our professional information systems (IS) lives and they cannot be ignored. With the success of Java and the introduction of Microsoft's .NET technologies, objects are becoming a major part of the IS equation. With the explosion of the Internet, now many years in the making, the electronic highway is really becoming an object-based highway. And as businesses gravitate toward the Web, they are gravitating toward objects, because the technologies used for the Web are mostly OO in nature.
The remainder of the article begins an overview of the fundamental OO concepts. The topics covered touch on some of the topics covered in subsequent installments, which explore these issues in much greater detail.