title: How do Gang of Four Design Patterns fit into the MVC paradigm?
body: <p>I've mulled over <em>Design Patterns</em> for some time now and I am just starting to see how I might actually begin incorporating some of these more deliberately in my development work. However, I am still confused about their treatment of MVC in the beginning of the book and how it relates to the rest of the book.</p>
  
  <p>Most of the frameworks I have worked with - Spring, Yii, ASP.NET, and even Objective-C Cocoa (UIKit) - cater to the MVC paradigm. I get MVC because to me it is a useful way of classifying objects and how they should message or interact with each other. Plus, these frameworks kind of force it upon you even if you are not setting out to think in the MVC way.</p>
  
  <p>I also feel that I understand the premise of <em>Design Patterns</em>: they <strong>really</strong> don't like subclassing, they love abstract interfaces, and they strive for loose coupling. I can't say I fully understand all of the patterns yet or how they are useful, but I am getting a feel for it.</p>
  
  <p>My question is this: what is the interplay between MVC and design patterns? What were they getting at in the first chapter of the book with the MVC application example? Are certain design patterns just not relevant in the MVC paradigm? I wonder, for example, how the Command pattern is supposed to fit into MVC. It seems incredibly useful, but do we create a <code>CommandModel</code> and <code>CommandController</code> to send to other controllers? Do we just create a <code>Command</code> object as prescribed in the book? Basically, I am wondering if the ideas of MVC and <em>Design Patterns</em> are wholly disjoint and I just don't understand, or if there are some patterns that do not fit into the mold.</p>