[MUSIC] Welcome to the third module in this course. So far, you've learned about creational, structural and behavioral design patterns. In this module, you will learn about the MVC or model view controller design pattern. This is a pattern that builds upon design patters that you've learned about in the first two modules. You will also learn about several general design principles that underly the design patterns to achieve software that is reusable, flexible and maintainable. You will then move on to learn about ways to analyze and critique your code for bad design. You will learn about many common malpractices and why they lead to bad design. In the software industry, these are often referred to as antipatterns or Code Smells. By the end of this module, you'll have the knowledge that you'll need to tackle the remaining capstone assignments for this course. So, let's get started. Imagine you are hired by a small grocery store in your neighborhood. Their cashiers are complaining about the old style cash systems where they have to manually type out the price of each and every item. At the same time, the customers are starting to get tired of waiting in line for purchases to be made this way. What they need is a system for entering and displaying orders. In other words, a user interface. The customer and the cashier should see the items that are entered into the order using a bar code scanner. They should also be able to see the total bill amount. Cashiers will like it, because they don't have to type item prices anymore. And customers will like, because orders get done faster and they can see the item prices on the screen. If mistakes are made, the cashier can easily make corrections and everyone is happy. Any time you hear user interface, you should consider using an MVC pattern. MVC stands for model view controller. The MVC pattern divides the responsibilities of a system that offers a user interface into those three parts. Let's look at a diagram of a simple MVC pattern. First, let's talk about the model. The model contains the underlined data and logic users want to see and manipulate. In the case, the cashiers and customers want to be able to put together grocery orders. A key part of the MVC pattern is that the model is self-contained. It has all of the state, methods and other data that it needs to exist on its own. Next stop is the view. The view is just like it sounds. It gives the user a way to see the model or at least parts of it. At the grocery store, this would be the screen that shows the list of items and their prices. Sometimes, the view will also have interaction elements like buttons and fields that allow the user to interact with the system. Well, the model is the back end, the underlying software. The view is more like the front end, the presentation layer. Although our example will only have one view, it is possible to have several views, all used within the same model. When some value changes in the back end or the model, it has to tell the view to update itself accordingly. This is done by using the Observer Design Pattern. Remember, in the observer pattern, the observers act like subscribers. In this case, any view is also an observer. When the model changes, it notifies all the views that are subscribed to it. The view may also have ways for a user to make changes to the data in the underlying model. If you were a cashier at a grocery store, in what ways could you change the order? Well, you could delete items if customers change their mind or change the prices of items to make corrections. You've probably seen buttons for these actions. In the MVC pattern, the view does not directly send requests to the model. Instead, information about the user interaction is passed to a controller which is responsible for interpreting these requests and changing the model. This way, the view is only responsible for the visual appearance of the system and the model focuses solely on managing the information for the system. Thus, the MVC pattern basically uses the separation of concerns design principle to divide up the main responsibilities and interactive system. In general, the model corresponds to those entity objects derived from analyzing the problem space for the system. A view corresponds to a boundary object at the edge of your system that deals with users. A controller corresponds with control object that receives events and coordinates action. Think about the cashiers at the grocery store. The model could be very complex, but let's use a simplified version. The store order model will simply be a grocery list with prices and a few methods to modify the order. The view will display the list of items with their prices and the total price. The cashier would like to be able to fix mistakes too. So let's include two buttons we talked about. Delete Item and Change Price. Let's follow what could happen when the change price button is pressed. The cashier presses the change price button, an event handler for this button calls the controller. The controller reads a new price from a text field on the view and uses these two pieces of information, the item to be changed and the new price to request a price change in the model using a method in the model. The controller could also check that the price is valid and ask the view to clear the text box. The model has now changed the price of one of the items. Since the view is an observer of the model, t he model will notify the view that it has changed and the view will update itself. The cashier's display now shows the new price. So, how is this implemented? Let's start with the most essential part, the model. The model should be able to exist on its own with no views or controllers. Of course, you will probably use views and controllers to see and change the model. But the model should not rely on a view or controller to exist. Since our view is going to be an observer, we have to make the model unobservable. We will use the java.util package to implement this behavior. Java.util contains an observable class that you can extend. If you import java.util and then extend observable, your store order class will allow you to add your views as observers. That way, they will act like subscribers of the store order and update whenever an order is updated. This class has several methods that modify itself. You can add items, delete items and change prices. Of course, a real order model will probably have more. But these basic functions are a good start. Notice that our model doesn't have any use interface elements and is not aware of any views. It will update the views through the observer pattern. Whenever changes are made, the setChanged method flags the change and the notifyObservers method notifies the view, so that they can update themselves. Let's have a look at one of these views. Since your OrderView class implements the observer interface, you must provide and update method. Notice that you had to downcast your store order in order to get the Ket item list and get price list methods. If you would like to make your code more type safe, you could develop your own observer pattern with generics. What happens when we use the view to modify the model? Look at the event handling here, notice that nothing here calls a method of the model. Instead, they call methods of the controller. The controller might look something like this. In this example, the controller is very simple, but there are still a few things we can learn. The controller must have references to both the view and model that it connects. Crucially, the controller does not make changes to the state of the model directly. It calls methods of the model to make changes. Using a controller, makes the code better in a few ways. First of all, the view can focus on its main purpose. Presenting the user interface, the controller takes the responsibility of interpreting the input from the user and working with the model based on that input. Separating these concerns makes the code cleaner and easier to modify. Secondly, with the controller in between the model and the view, the view is no longer tightly coupled to the model. While you are developing, you might add features to the model and test them long before putting them in the view. Like other design patterns, there's no one way to use the MVC pattern. You may find that your program needs a bit of a different approach. The defining feature of the MVC pattern is the separation of concerns between the back end, the front end and the coordination between the two. While their example had one class each for the model, view and controller. Software systems generally will have multiple model classes, view classes and controller classes. You will find the model view controller pattern in just about any application with a user interface. Let's review the components. The model contains the underlying data, state and logic that the user wants to see and manipulate. The view presents the model information to the user in the way they expect it and allows to interact with it. A model could have several views that present different parts of the model or present the model in different ways and the controller interprets the user's interaction with elements in the view, and modifies the model itself. The controller ensures that the views and the model are loosely coupled and allows the view to be mainly concerned with user interface concerns. Separating these functions makes the code easier to develop, read and maintain. This separation of concerns allows your program to be modular and loosely coupled. Loose coupling is especially important in large development teams. One team of developers may be working on the front end, the user interface or views while another team works on the back end, the model. Even if you're coding a project on your own, separating these will allow you to focus on each set of responsibilities separately. You can more easily replace the views to use a different user interface toolkit while keeping the model the same.
