Now, while our app works at the moment and we can use it and it's got pretty much all the functionality 1
we need, there's just one problem. 2
Our code is not in very good shape. 3
All of our logic is pretty much stuffed into our ViewController.swift and it's just a bit of a mess 4
in here. 5
Well, why is this a problem? 6
What's wrong with having just one file with lots of code? 7
Imagine if we had, say, 100 questions, we would even struggle finding our function than our viewDidLoad 8
and figuring out what's actually going on in here. 9
Even for a relatively simple app, the logic is already getting a bit out of hand. And the classic metric 10
of "Do you think you could understand what's going on in your code if you came back to it in three months?" 11
Well, you might or you might not. 12
So in order for us to be able to build more complex apps, we need to understand the concept of design 13
patterns. 14
A design pattern is what can help us get organized and structure our code in a better way. 15
So what is a design pattern? 16
A design pattern is simply a proven solution to a common problem. 17
So what exactly is the common problem that we need to solve? 18
Well, with software, it's usually complexity. And we can see this in our app. All of our apps logic and 19
all of our apps code is stuffed into a single file that's getting increasingly long and increasingly 20
complex. Let's say that you had a windmill that you had to manage to generate some electricity. Well, you 21
could probably manage it just by yourself and you could live in the windmill. You would have a joyous 22
life. 23
But what if, instead, you had to manage a whole nuclear power plant. It'd be really difficult to do it 24
by yourself. 25
And if you did it badly, you might end up with a Chernobyl situation on your hands, and nobody wants that. 26
So if we think of software as a busy restaurant, if one person had to do everything from cooking, to taking 27
orders, to cleaning dishes, well, that person would work really hard, but they still wouldn't be able to 28
serve many customers. 29
So you might think that the solution is simply more staff, more code. But actually a restaurant full of 30
staff who don't know what they're doing would be complete mayhem. 31
So what do we need instead? 32
Well, the best restaurants have staff who know exactly what they're supposed to do at any given point 33
in time. 34
And it's the same thing 35
managing complexity everywhere. 36
Companies have a lot of complexity and so do software. 37
So we need to come up with an org chart for our software. 38
Now, this is a hotly debated topic. 39
What is the best design patterns to use for X? 40
And people have really strong opinions. 41
Some people say that, "Oh, everyone should use VIPER, and your colleague John might say, "No, you should always 42
use MVVM." If you've never heard any of these acronyms, 43
don't worry about it. 44
There are so many different design patterns that you could possibly choose from. So much so that I've 45
filled up an entire screen of some of the ones that come to the top of my head. 46
Now, the thing to remember is there isn't such a thing as the one best, ultimate design pattern that you 47
should learn and always use, and never think about any of the other ones. Because at the end of the day, 48
a design pattern is kind of like an architectural blueprint, right? 49
And depending on what your requirements are, you might have a different architectural blueprint. Say, if 50
you needed to live in the Arctic, then you might need the blueprint for building an igloo. If you wanted 51
to live on top of a tree, 52
for some reason, then you would need the architectural pattern for building a treehouse. Depending on 53
what app you're building, 54
you might need to use different design patterns. And on top of that, there's also style based choices 55
where you might be the sort of person who wants to live in an entirely pink house with irregularly shaped 56
windows. 57
But you might also prefer a different style. And it's the same story with design patterns. 58
For some programmers, they want to have as few lines of code as possible, while others want their code 59
to be as readable as possible. So in this lesson, we're going to learn about the most fundamental design 60
pattern that everyone who's learning how to make mobile apps should know about. And also the design pattern 61
that Apple chooses to use. 62
And this is, of course, the MVC design pattern or the Model-view-controller. 63
Now, how does this work? Well ,we split our project into three main components: the model, the view, and the 64
controller. And by making these three components work together, we end up with the MVC design pattern. 65
The M stands for model, and in order to create the model, we separate out the parts of our code which 66
handles all the data and the logic of dealing with that data. 67
And then, we have a view component. 68
And these are the parts of our code which handle what goes onto the User Interface and deals with user 69
interaction. 70
Now, finally, we have our C which is our controller. And this is the mediator of it all, 71
the conductor if you will. 72
And so if we had an app where the user taps on the User Interface, then we would get a message from the 73
view component to our controller sending over those input events. And then, our controller interprets 74
that and maybe makes a request to our model for some data, and the model will implement some business 75
logic and process the data in some sort of way, and then it outputs some formatted data and sends it 76
back to the controller. 77
Now, finally, the controller takes that data, interprets it, and sends the relevant parts to the view to 78
modify the User Interface. 79
So the view and the model never directly talk to each other, and it's only through the controller that 80
they're able to interact. 81
So why is this pattern so useful in app programming? 82
Why do you need to separate the model and the view? 83
Well, imagine if your newly built quiz app becomes so popular on the App Store that users are demanding 84
a version in German and French, 85
others want a history version, and a science version, and a humanities version of the quiz app. 86
Now, if you had created your app using the MVC design pattern, then you won't actually need to touch the 87
controller or the view, all you would need to modify it to change the app for this purpose is to switch 88
out the model. 89
You might need to update the logic a little bit. 90
You might need to update the data. But you won't need to go into the ViewController.swift file or 91
the Main.storyboard or any of the design files. So MVC is really great for reusing code, 92
separating out your components, so that they are modular. And this also happens to reduce errors and makes 93
your program much easier to understand, especially for other programmers who already know about the MVC 94
design pattern. 95
In the next lesson, we're actually going to take the theory that we've learned and apply it to our app, 96
and use the Model-view-controller design pattern.