Code reuse is alleged to be one of the prime benefits of object-oriented programming.
Rather than solving a problem from scratch, you simply derive a subclass
from an existing class and override a few methods.
The reality is considerably less promising than the theory.
Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages
like Java and C++ rather than procedural languages like
( C, Fortran 77, and Cobol). This site chose Java and C++ for pragmatic reasons:
Our day-to-day experience has been in these languages, and they are increasingly popular.
The choice of programming language is important because it influences one's point of view. Our patterns assume Java and C++ level language features, and that choice determines what can and cannot be implemented easily.
If we assumed procedural languages, we might have included design patterns called "Inheritance," "Encapsulation," and "Polymorphism.
But since these OO-Design Principles are already part of the Java language, these elements are not classified as patterns.
The fact is, designing classes
is hard, and designing reusable classes is even harder.
The best estimates reveal that even experienced object-oriented programmers take three times as long to design a class that can be reused in other contexts as they do to solve the immediate problem they face.
Given this time cost, it is no wonder that few programmers explicitly code for reuse. Software projects are routinely understaffed, under-budgeted and over deadline.
Although a class you actually reuse can repay its cost of development on the fourth project, few organizations have the human capital needed to invest in truly reusable code.
In fact, reuse is often considered only by companies developing class libraries for third party use,
where the extra cost of designing for reuse can be repaid hundreds of times over on many thousands of different projects.