CSC/ECE 517 Fall 2012/ch2a 2w14 bb: Difference between revisions
| Line 3: | Line 3: | ||
= Design Patterns = | = Design Patterns = | ||
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. | |||
== Why Patterns == | == Why Patterns == | ||
== Why Design Patterns == | == Why Design Patterns == | ||
== Categorization of Patterns == | == Categorization of Patterns == | ||
== Benefits of Design Patterns == | == Benefits of Design Patterns == | ||
= Pattern Fragility = | = Pattern Fragility = | ||
== What is Pattern Fragility == | == What is Pattern Fragility == | ||
Revision as of 20:45, 24 October 2012
Introduction
The purpose of the wiki is to introduce and show some example about pattern fragility. The contents include definition of pattern fragility and what does the concept cover. We also give some examples of mistakes in code that spoil the benefits of design patterns.
Design Patterns
A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.