A pattern is defined as a rule that expresses a relation between a problem, a context and a solution [Gamma et al., 1995]. Software patterns represent simple solutions that have proven successful and that can be applied to any of the activities in the life cycle such as analysis or design. They capture experience in a consistent and methodical way so that it can be easily reused and learned. Patterns do not include actual code. As a matter of fact, a framework is sometimes defined as a set of patterns plus code [Johnson, 1997]. According to [Beck and Johnson, 1994], patterns can be used to derive an architecture from an initial problem where an architecture is understood as the way the parts work together to make the whole [Garlan and Shaw, 1993]. Patterns are not metaphorical but rather metonymycal as, in some sense, you substitute some attribute or cause or effect of the thing for the thing itself [Noble et al., 2002].
The main difference between patterns and frameworks is that patterns represent design reuse while frameworks, apart from design, they also represent analysis and implementation reuse. Nevertheless, because some frameworks such as the Model View Controller have been implemented a number of times they have also become some sort of pattern [Johnson, 1997].