Hello.
In this video, we're going to find the answer to the question for.
What is the spaghetti code?
Spaghetti code is a pejorative term used to describe cold that is messy, tangled and hard to maintain.
You can imagine such code as a bowl of spaghetti with all pasta.
Ferraz being untangles together, making it very hard to say where one starts and word you ever erns.
It would be hard to follow a single friend without moving the others.
And it is as hard to make any change in the spaghetti code without affecting many other areas of code.
There are plenty of issues that make cold spaghetti code.
So let's just list a couple of them.
Huge grasses and mustard's multiple responsibilities in one class using the go to cute, but naming
magic numbers and cold repetitions.
You can learn more about those topics in the form of lectures.
Let's see some spaghetti code and then let's try to refactor it.
Imagine you were told to implement such an interface.
The class implementing such an interface should calculate the roots of a quadratic function that is
defined by a user via console interaction.
This interface is not very good since the calculate method returns void.
It forces the implementer to mix reading from the console with actual words calculation.
But let's just leave it as it is for the purpose of the exercise.
Before we start, just a quick reminder.
The quadratic function looks like this, and this is how you calculate the roots of a quadratic function.
Now let's see spaghetti code that actually implements the interface we defined before.
Brace yourself as this is going to be ugly.
All right.
It may take a while to read it all.
So I recommend checking out the repository I linked to this course.
Let's just take a quick look at this graph.
First of all, it's quite big.
This file is over 100 lines long.
The plenty of things here that are just terrible.
Not only is this court hard to read and understand, but it is also a breeding ground for bugs.
Also, if we need to make other changes in this code, it would be laborious and error prone.
Let me point out some of the most outstanding problems in this code.
First of all, one class is doing everything.
There is a lot of bad naming.
For example, this variable also there are unnecessary comments.
Instead of this comment, we should simply rename discoverable to is finished and remove the comment.
There are a lot of cold repetitions.
For example, this code is repeated three times for each of the A, B and C variables.
Also, there are even more unnecessary comments since the code itself says that we are reading a here.
No need to add a comment.
The formatting is inconsistent and just about, for example, in this part of the code, those bracers
are a new line here, but in the same line here, also, there is a lot of redundant calculations.
Like, for example, here we're trying to parse string to double twice.
All right.
I think it might be an interesting exercise for you to try to refactor this code.
Let me show you how I did it.
So this is the main course, the one that actually implements the interface.
As you can see, this class is much smaller now.
I've moved the operations of reading from the council to our separate class called Council Reader.
I've also created Muffie Utilities class that only deals with the actual calculation of the square function
routes.
Since this calculation produces a result that may have zero one or two numbers within.
I also created a special class quadratic function roots to represent such a result.
Let's see those classes.
First, the console reader.
As you can see, the only purpose of this class is to provide functions for reading from the console.
I created a metal trick double that given a variable name, asks the user to enter this variable and
then tries to pass it to Darbo.
I've also added a similar method, but for reading books, it's just asking to type Y or N. and passes
it to true or false.
Now let's see the Matthew 286.
As you can see, this class is really simple.
The only thing it does is a pure mathematical calculation, given a quadratic function formula.
It calculates its function rules.
As we said, there can be zero one or two routes.
I created a special type to represent that.
Let's see it.
This glass can hold zero one or two results within it exposes the first root and second root properties,
which throw exceptions if an invalid operation executed.
For example, if the programmer tries to redo the second root of a result, that only has one root.
Of course, we also have wayang properties to check how many roots there are.
And here we have the constructors.
As you can see, this is pretty simple.
Let's summarize what happened.
The code got divided into smaller, more cohesive classes.
They are now called repetitions now.
Naming is better.
And the code style is consistent.
No comments are added since no comments are needed.
The code speaks for itself.
Is this code perfect?
Of course not.
No code is perfect.
That's for sure.
I see a couple of things that could be improved, which I skipped for brevity sake.
First, the console reader should not be a static class.
It should rather implement an interface like a user input reader.
This way, we could easily charge the implementation to, for example, reading user input from a firm
in a desktop application.
Also, this class has a very specific implementation that would probably have to be generalized.
One more muttons for reading various types would be added.
Also, writing to the console should not be done with console runtime.
This way, this class is starting coupled with the console class.
What if we decide to change the way of communicating with the user?
This should be, again, some interface like a user message writer.
You may argue that this code is actually longer than it was before refactoring.
Is it about Fik?
No, it isn't.
Called refactoring naturally leads to creating more classis methods and data structures.
Also, please note that I added a brand new entity for representing the roots of the quadratic function.
It allowed me to have clean, well named and simple to use operations on the not so simple result of
quadratic function roots calculation in a real life project.
We could have thousands of places where quadratic functions would be used, and having a well-defined
class to represent its result would be critical.
Lock-Out is not an issue tangoed messy and readable and complicated code is don't be afraid to make
your code longer during the refactoring.
You will still spend less time working on this code than you would spend working on the code.
That is shorter.
But Agler.
All right, let's summarize.
The spaghetti code is a pejorative term used to describe code that is messy, tangled and hard to maintain.
There are actually more pasta related metaphors used to describe, but gold and you might be asked about
them during the interview.
For example, what is the ravioli code?
The ravioli code is a term that describes code, that contains classes that are easy to understand in
isolation.
But interactions between them and the project as a whole are not or might be.
What is the lasagna code?
The lasagna code is a code whose layers are complicated and so are the interactions between them.
Making a change in one of their heavily affects other layers.
All right.
I hope I didn't make you hungry.
Thanks for watching this video and see you in the next one.
When we start, the important topic of the design putters.