In this video, we will analyze the issues in the code of the Todo list app. 1
This will help us understand why we need object-oriented programming. 2
We will learn what procedural programming is and what problems it can cause. 3
Additionally, we will understand what an anti-pattern is and, specifically what spaghetti code anti-pattern 4
is about. 5
Finally, we will learn what high quality code must always be ready for. 6
Before we understand what object-oriented programming is, let's take a look at the code of the Todo 7
list app we created in the first section. 8
We will try to see what is the structure of this program. 9
The design here is simple. 10
The code is executed from top to bottom. 11
The program stops once we reach this line. 12
Everything below is the methods we created to improve the readability and reusability of the code. 13
This doesn't look so bad for now, but this is a very simple application. 14
If it grows, this file will grow as well and it will become harder and harder to read. 15
If you wonder how big real world applications can be, let me tell you that the largest project I worked 16
on had over 2 million lines of code in total. 17
We could perhaps split this file somehow and place some of those methods in their own *.cs files, but 18
this would raise other problems. 19
For example, what if we wanted to limit who can call those functions? 20
Sometimes it is necessary if, for instance, the function modifies some critical data. 21
Also, even with functions moved to their dedicated files, the main logic of the program, which utilizes 22
them, may still be very long and complex. 23
Another issue here is that there is no separation by the levels of abstraction. 24
It is a good practice to separate high-level business decisions from low-level technical details. 25
For example, a high-level business decision says that the user can see, add or delete todos. Low-level 26
detail is that they can communicate with the program via the console. 27
The thing about low-level details is that they often change. 28
The feature of adding TODOs is unlikely to be removed, but communication via console can be switched 29
to something else. 30
If we as developers are one day asked to modify this application to have some graphical user interface 31
we'll have no easy way of achieving this with the current design. 32
Sometimes we are not simply asked to change the behavior of the code. 33
Instead, we are asked to give the ability to have two or more different behaviors depending on some 34
configuration. 35
Imagine that the todo list app user could decide to store the todos directly on their device or in 36
the cloud, depending on some settings. 37
Currently, this would be complicated and would involve filling our code with multiple if statements. 38
This code would not be easy to maintain, meaning any future code changes would be painful to implement. 39
It is crucial that we create our code in such a way that it is easy to be modified in the future because 40
the requirements change very often. 41
The paradigm this code is in line with is called procedural programming. 42
The program is composed of procedures called methods, in our case, each containing a series of steps. 43
Those procedures are called from some main flow of the program or from one another. 44
We already mentioned some of the problems this paradigm can cause. 45
In general, it leads to creating something we call spaghetti code: a messy, tangled code as hard to 46
follow as following a single thread in a bowl of spaghetti. 47
It is hard to move or remove a single thread from such a bowl without moving anything else. 48
Similarly, it is hard to change anything in the spaghetti code. And this is something I want to emphasize 49
again: 50
we must always be ready for the requirements to change and to adjust our code to them. 51
Change is the only constant in programming. 52
There are very few projects where the complete requirements are known in detail before developers start 53
the work, and never change during the development process. 54
Think of applications like Facebook, YouTube or Steam. 55
You probably see some changes in them every few weeks. 56
By the way, spaghetti code is an example of an antipattern, so something we should avoid if our code 57
is supposed to be of high quality. 58
We'll learn more about antipatterns and avoiding them later in the course. 59
We mentioned some of the issues caused by procedural programming. 60
They have been the pain in developers necks for a long time. 61
As a solution, a new paradigm called object-oriented programming was invented in the 60s and became 62
popular in the 90s. 63
Today it is the most followed paradigm and most mainstream programming languages support it.