Pitfalls of Object-Oriented Development
- Underestimating the difficulty of reuse
- Doing OO development with the explicit goal of reuse is harder and takes
- Any deficiencies in generality won't show up until reuse is attempted.
- All the "low hanging fruit" is already provided by the operating system or
- Having or setting unrealistic expectations
- OO development does not guarantee reusable components
- Even "standard" components routinely require a lot of manual cutting,
shaping, fitting, and binding.
- Objects and subsystems created for one application may have very little
relevance for another.
- Reuse may outstrip the skills and experience of the developers involved.
- Being too focused on code reuse
- Design reuse is often neglected in favor of code reuse. The most
important creation to come from an OO project is often the architecture
and design, not the implementation.
- Focusing on a "lines of code reused" can be as meaningless and
self-defeating as the classic "lines of code" metric.
- Emphasis on "tangible" classes and code can divert organizational
attention from more strategic and abstract framework opportunities.
- Not investing in reuse
- Reuse costs effort in analysis, design, implementation, and testing.
- Reuse may cost additional staff.
- OO development in general, and reuse in particular, must be supported
as a long term investment.
- Generalizing after the fact
- "There is never enough time to get it right, there is only enough time
to get it done."
- It is usually easier and faster to write a specific solution than a
- Generalizing late requires untangling implicit and explicit dependencies
that have crept in.
- Allowing too many connections
- A complex class may have a dozen of or more other classes to which it
refers, each of which will have its own list of dependencies, and so on.
- Class dependencies should be mapped out during the analysis and design
phases and should be tracked as implementation proceeds.
- You'll probably rearchitext two or three times before you begin in order
to get it right.
- Allowing circular dependencies
- A circular dependency is one in which you start with a class and trace its
dependencies until you get back to that same class.
- The problem with circular dependencies is not the tight cohesion that will
occur within a subsystem, it is dependencies that loop through two or more
- Once more, with feeling: Component reuse must be planned for and designed
into a project from the start.