0
1
00:00:00,480 --> 00:00:07,230
Now, while our app works at the moment and we can use it and it's got pretty much all the functionality
1

2
00:00:07,230 --> 00:00:10,270
we need, there's just one problem.
2

3
00:00:10,350 --> 00:00:13,630
Our code is not in very good shape.
3

4
00:00:13,740 --> 00:00:19,890
All of our logic is pretty much stuffed into our ViewController.swift and it's just a bit of a mess
4

5
00:00:19,890 --> 00:00:20,340
in here.
5

6
00:00:21,300 --> 00:00:23,220
Well, why is this a problem?
6

7
00:00:23,220 --> 00:00:27,060
What's wrong with having just one file with lots of code?
7

8
00:00:27,210 --> 00:00:34,620
Imagine if we had, say, 100 questions, we would even struggle finding our function than our viewDidLoad
8

9
00:00:34,620 --> 00:00:37,240
and figuring out what's actually going on in here.
9

10
00:00:38,010 --> 00:00:45,270
Even for a relatively simple app, the logic is already getting a bit out of hand. And the classic metric
10

11
00:00:45,270 --> 00:00:51,210
of "Do you think you could understand what's going on in your code if you came back to it in three months?"
11

12
00:00:51,210 --> 00:00:53,870
Well, you might or you might not.
12

13
00:00:53,880 --> 00:01:00,300
So in order for us to be able to build more complex apps, we need to understand the concept of design
13

14
00:01:00,300 --> 00:01:01,470
patterns.
14

15
00:01:01,810 --> 00:01:07,240
A design pattern is what can help us get organized and structure our code in a better way.
15

16
00:01:07,260 --> 00:01:10,620
So what is a design pattern?
16

17
00:01:10,620 --> 00:01:16,290
A design pattern is simply a proven solution to a common problem.
17

18
00:01:16,320 --> 00:01:20,100
So what exactly is the common problem that we need to solve?
18

19
00:01:20,100 --> 00:01:27,510
Well, with software, it's usually complexity. And we can see this in our app. All of our apps logic and
19

20
00:01:27,570 --> 00:01:33,870
all of our apps code is stuffed into a single file that's getting increasingly long and increasingly
20

21
00:01:33,870 --> 00:01:43,340
complex. Let's say that you had a windmill that you had to manage to generate some electricity. Well, you
21

22
00:01:43,340 --> 00:01:48,710
could probably manage it just by yourself and you could live in the windmill. You would have a joyous
22

23
00:01:48,710 --> 00:01:49,120
life.
23

24
00:01:49,460 --> 00:01:56,630
But what if, instead, you had to manage a whole nuclear power plant. It'd be really difficult to do it
24

25
00:01:56,630 --> 00:01:57,480
by yourself.
25

26
00:01:57,680 --> 00:02:03,320
And if you did it badly, you might end up with a Chernobyl situation on your hands, and nobody wants that.
26

27
00:02:04,100 --> 00:02:11,480
So if we think of software as a busy restaurant, if one person had to do everything from cooking, to taking
27

28
00:02:11,510 --> 00:02:17,780
orders, to cleaning dishes, well, that person would work really hard, but they still wouldn't be able to
28

29
00:02:17,780 --> 00:02:19,880
serve many customers.
29

30
00:02:19,880 --> 00:02:26,780
So you might think that the solution is simply more staff, more code. But actually a restaurant full of
30

31
00:02:26,780 --> 00:02:31,370
staff who don't know what they're doing would be complete mayhem.
31

32
00:02:31,370 --> 00:02:33,800
So what do we need instead?
32

33
00:02:33,800 --> 00:02:39,530
Well, the best restaurants have staff who know exactly what they're supposed to do at any given point
33

34
00:02:39,530 --> 00:02:40,270
in time.
34

35
00:02:40,550 --> 00:02:41,810
And it's the same thing
35

36
00:02:41,870 --> 00:02:44,210
managing complexity everywhere.
36

37
00:02:44,210 --> 00:02:48,260
Companies have a lot of complexity and so do software.
37

38
00:02:48,260 --> 00:02:53,300
So we need to come up with an org chart for our software.
38

39
00:02:53,300 --> 00:02:56,560
Now, this is a hotly debated topic.
39

40
00:02:56,600 --> 00:03:00,380
What is the best design patterns to use for X?
40

41
00:03:00,380 --> 00:03:03,290
And people have really strong opinions.
41

42
00:03:03,290 --> 00:03:10,520
Some people say that, "Oh, everyone should use VIPER, and your colleague John might say, "No, you should always
42

43
00:03:10,520 --> 00:03:14,270
use MVVM." If you've never heard any of these acronyms,
43

44
00:03:14,270 --> 00:03:15,610
don't worry about it.
44

45
00:03:15,650 --> 00:03:22,070
There are so many different design patterns that you could possibly choose from. So much so that I've
45

46
00:03:22,070 --> 00:03:25,910
filled up an entire screen of some of the ones that come to the top of my head.
46

47
00:03:26,600 --> 00:03:34,130
Now, the thing to remember is there isn't such a thing as the one best, ultimate design pattern that you
47

48
00:03:34,130 --> 00:03:40,610
should learn and always use, and never think about any of the other ones. Because at the end of the day,
48

49
00:03:40,970 --> 00:03:45,950
a design pattern is kind of like an architectural blueprint, right?
49

50
00:03:46,040 --> 00:03:52,430
And depending on what your requirements are, you might have a different architectural blueprint. Say, if
50

51
00:03:52,430 --> 00:03:59,510
you needed to live in the Arctic, then you might need the blueprint for building an igloo. If you wanted
51

52
00:03:59,510 --> 00:04:01,230
to live on top of a tree,
52

53
00:04:01,250 --> 00:04:06,830
for some reason, then you would need the architectural pattern for building a treehouse. Depending on
53

54
00:04:06,830 --> 00:04:08,570
what app you're building,
54

55
00:04:08,600 --> 00:04:14,960
you might need to use different design patterns. And on top of that, there's also style based choices
55

56
00:04:15,620 --> 00:04:21,770
where you might be the sort of person who wants to live in an entirely pink house with irregularly shaped
56

57
00:04:21,830 --> 00:04:22,570
windows.
57

58
00:04:22,700 --> 00:04:29,160
But you might also prefer a different style. And it's the same story with design patterns.
58

59
00:04:29,330 --> 00:04:35,570
For some programmers, they want to have as few lines of code as possible, while others want their code
59

60
00:04:35,570 --> 00:04:43,310
to be as readable as possible. So in this lesson, we're going to learn about the most fundamental design
60

61
00:04:43,310 --> 00:04:49,340
pattern that everyone who's learning how to make mobile apps should know about. And also the design pattern
61

62
00:04:49,370 --> 00:04:51,460
that Apple chooses to use.
62

63
00:04:51,500 --> 00:04:58,040
And this is, of course, the MVC design pattern or the Model-view-controller.
63

64
00:04:58,040 --> 00:05:07,740
Now, how does this work? Well ,we split our project into three main components: the model, the view, and the
64

65
00:05:07,740 --> 00:05:15,360
controller. And by making these three components work together, we end up with the MVC design pattern.
65

66
00:05:15,360 --> 00:05:21,990
The M stands for model, and in order to create the model, we separate out the parts of our code which
66

67
00:05:21,990 --> 00:05:26,080
handles all the data and the logic of dealing with that data.
67

68
00:05:26,400 --> 00:05:29,600
And then, we have a view component.
68

69
00:05:29,760 --> 00:05:36,300
And these are the parts of our code which handle what goes onto the User Interface and deals with user
69

70
00:05:36,300 --> 00:05:37,830
interaction.
70

71
00:05:37,830 --> 00:05:43,670
Now, finally, we have our C which is our controller. And this is the mediator of it all,
71

72
00:05:43,710 --> 00:05:46,170
the conductor if you will.
72

73
00:05:46,170 --> 00:05:53,670
And so if we had an app where the user taps on the User Interface, then we would get a message from the
73

74
00:05:53,670 --> 00:06:01,770
view component to our controller sending over those input events. And then, our controller interprets
74

75
00:06:01,770 --> 00:06:09,330
that and maybe makes a request to our model for some data, and the model will implement some business
75

76
00:06:09,330 --> 00:06:16,380
logic and process the data in some sort of way, and then it outputs some formatted data and sends it
76

77
00:06:16,380 --> 00:06:18,210
back to the controller.
77

78
00:06:18,210 --> 00:06:25,230
Now, finally, the controller takes that data, interprets it, and sends the relevant parts to the view to
78

79
00:06:25,230 --> 00:06:27,640
modify the User Interface.
79

80
00:06:27,900 --> 00:06:34,650
So the view and the model never directly talk to each other, and it's only through the controller that
80

81
00:06:34,650 --> 00:06:36,500
they're able to interact.
81

82
00:06:36,540 --> 00:06:40,350
So why is this pattern so useful in app programming?
82

83
00:06:40,350 --> 00:06:43,860
Why do you need to separate the model and the view?
83

84
00:06:43,890 --> 00:06:50,610
Well, imagine if your newly built quiz app becomes so popular on the App Store that users are demanding
84

85
00:06:50,610 --> 00:06:53,340
a version in German and French,
85

86
00:06:53,340 --> 00:07:00,130
others want a history version, and a science version, and a humanities version of the quiz app.
86

87
00:07:00,150 --> 00:07:07,140
Now, if you had created your app using the MVC design pattern, then you won't actually need to touch the
87

88
00:07:07,140 --> 00:07:14,730
controller or the view, all you would need to modify it to change the app for this purpose is to switch
88

89
00:07:14,730 --> 00:07:15,880
out the model.
89

90
00:07:15,960 --> 00:07:18,150
You might need to update the logic a little bit.
90

91
00:07:18,150 --> 00:07:23,490
You might need to update the data. But you won't need to go into the ViewController.swift file or
91

92
00:07:23,490 --> 00:07:32,080
the Main.storyboard or any of the design files. So MVC is really great for reusing code,
92

93
00:07:32,210 --> 00:07:39,530
separating out your components, so that they are modular. And this also happens to reduce errors and makes
93

94
00:07:39,530 --> 00:07:45,740
your program much easier to understand, especially for other programmers who already know about the MVC
94

95
00:07:45,740 --> 00:07:46,580
design pattern.
95

96
00:07:48,520 --> 00:07:53,650
In the next lesson, we're actually going to take the theory that we've learned and apply it to our app,
96

97
00:07:54,190 --> 00:07:57,100
and use the Model-view-controller design pattern.