Fundamentals of programming, design patterns. What are design patterns? One way of looking at design patterns is that they are micro architectures. As such, they tell us what pieces we need, and how they interact. When we say interact, we mean both internal interactions within the design pattern, and how other code would interact with the design pattern. As such, design patterns provide guided frameworks for building solutions, and tend to be well-established, best-practice type guidance. An example of a design pattern would be the model view controller design pattern. MVC as it is better known, originated as a design pattern for implementing user interfaces. But is applicable to any form of interaction where a transport is connected to a model. How does MVC work, and why is it so generally applicable? The MVC pattern is made up of three basic architectural pieces. Controllers. Controllers receive requests, or messages. A controller is technology specific. It could be receiving a message from a network transport, from a language-specific MVC framework, from a message queue, from an event, because a button was clicked, or any other means by which it could receive a request. The controller could be a graphical button receiving a click. It could be a rest controller receiving an HTTP request. It could be a message driven bean receiving an MQ message. It doesn't matter in terms of the pattern, the role remains the same. The controller's first job upon receiving a message, aka request, is to understand it. What does the message say? In the current context, what must we do about the message? What data, aka parameters, is provided by the message? Having come to understand the meaning and context of the message, the controller identifies the business logic that it needs to use to carry out the request. This business logic is known as the model. The model is technology agnostic. It does not know about button events or HTTP messages, MQ messages, or anything else of that sort, it is simply plain business logic in whatever language you are working. The only new ones being that the MVC model in its full specification of the design pattern, allows the model to publish events, perhaps using another design pattern known as the observer pattern, to interested parties known as subscribers. But the fact is most modern MVC frameworks ignore that capability, and it's certainly a complication we don't need to belabor are taken into account at this time. For now, a model need be nothing more complicated than the pizza code we've already written. Once the controller has used the model to process the request, it's time to respond to the requester. This is the job of the view. Just as the controller is technology-specific to receive and decode a request, the view is technology specific to format and return the response. But the view arena gets even more interesting, because there could be multiple ways to represent the same information. If you asked for a list of cars, did you want it in HTML, in Excel format, in a PDF, in JSON, in XML, rendered in a window on the screen. In the case of the ones up to the window example, even though the transport might be the same, and this semantic concept the same, the actual format of the response may differ. There's usually a means for the controller to select the correct view from a list of options. For example, a temperature could be rendered as a number, a line, a radial graph in a think-tachometer, a drawn thermometer or other. Let's walk through the MVC interaction. First, the message aka request comes to the controller. The controller then receives and decodes the technology specific request. It decodes any parameters from the request, and finally identifies and invokes the aspects of the model necessary to carry out the request. Now the model performs the business logic actions, and if implemented notifies subscribers. Next, the controller chooses the view that will be used to respond to the request, and to complete the cycle the view will provide a technology specific output. There are many design patterns. MVC for example, dates back to the late 1970s in small talk. But in the early 1990s, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides undertook the promotion and publication of a set of design patterns for object oriented programming. There 1994 book Design Patterns, Elements of Reusable Object-Oriented Software is considered a seminal work on design patterns. It identifies catalogs and describes 23 design patterns. The authors, and sometimes by extension, the book itself became known as the Gang of four. Design patterns are important. They are pervasive in modern programming. Remember, they're micro architectures, and the developers of modern programming frameworks, not only chose to use various design patterns to implement the frameworks, they expect you to use them when working with those frameworks. Furthermore they provide best practices on how to structure your own code. We're going to continue our pizza example with a simple design pattern called the callback pattern. We're going to pass a data set to be processed, and a function to process one element from the data set, and we're going to pass that to a function. In terms of how we're going to go about this, there are other arguably better ways that we could do this in Python. But a, this is not a Python class. B, some of the nicer ways to do this in Python don't necessarily translate so easily into other languages. C, we're going to stick with the fundamental tools that we've given you as part of this programming fundamentals course.
