[Copyright (c) 1995, 2007 by Bruce F. Webster. All rights reserved. Last updated: 06/17/07]
CATEGORIES: conceptual
The previous pitfall (1.6) talked about development efforts being labeled “object-oriented†because they happened to be written in an object-oriented programming language. It can get worse than that.
Products, projects, and applications are sometimes considered object-oriented because they have one or more of the following attributes:
- They use a graphical user interface with windows and menus.
- They have icons on the screen that the user can drag around.
- They use an event-driven approach.
- They are broken up into modules.
- They create libraries which can be reused.
- They are part of a client/server or distributed application.
- They pass messages to other tasks or applications.
- They allow data from one application to be embedded within a document created by another.
None of these attributes inherently has anything to do with object-oriented design and implementation; all of them can be implemented using procedural engineering. (Heck, we implemented the first five back in 1984 in the SunDog game mentioned in the Introduction.)
Symptoms
Use of the term “object-oriented†in a way that doesn’t seem to make sense. Undue focus (positive or negative) on how the application looks.
Consequences
Mild to severe miscommunication, with all its attendant ills, including misdirected efforts. The worst consequence is wrong expectations for the results of your efforts, with the resulting impact on planning and delivery.
Detection
If you suspect that someone has fallen into this pit, ask her or him to define what exactly they think “object-oriented†means. Probe until you are convinced that the person understands the concepts of objects, classes, inheritance, instantiation, abstraction, encapsulation, and so on. If you keep getting talk about the items above, you may have trouble.
Extraction
Prepare a presentation on what “object-oriented development†does and does not mean. Without stepping on too many toes, illustrate which misconceptions may be floating around. Explain whether the project actually is object-oriented and what (if anything) can be done to make it so.
Prevention
Carry out the Detection and Extraction phases before the project gets off the ground. Explain just what it will mean if this project is to be truly “object oriented.†Point out the costs, the risks, the requirements, and the benefits. If expectations are centered on the attributes listed above, treat them as requirements or requests that are separate from the project’s object orientation.
Contributor/References
Webster, from Pitfalls (1994).
