| Software design is a fledgling discipline. When the “software crisis” came to be acknowledged during the late 1960s, software development projects have been marred by budget overflows and catastrophic failures. This situation has largely remained unchanged. Programmers still create poorly-understood systems of monstrous complexity which suffer from a range of problems directly linked to the lack of abstraction: lack of means of communicating design decisions, absence of effective pedagogic tools for training novice programmers, and inadequate means for maintaining gigantic software systems. In the recent years, we have witnessed an explosion of loosely-related software technologies, techniques, notations, paradigms, idioms, methodologies, and most of all proprietary and poorly-understood ad-hoc solutions, driven by market forces more than by design, planning, or research.
Design patterns were introduced to programming practices at the end of the 1980s as a result of dissatisfaction with software’s state of affairs. The few means of abstraction in existence at the time, such as algorithms and data structures, narrowly-suited procedural programming, poorly fitting with the growing use of object-oriented programming paradigm. For the first time, an abstraction technique at hand was general enough to be useful for practitioners and academics alike, specific enough to enter textbooks, broad enough to be useful during any stage in the development process, and generic enough to support any programming paradigm. The introduction of Design patterns marks a turning point in the history of software design. |
