The next topic is method structuring.
So here we have a class called Order Processor.
And inside here we have one public void called process order.
We have a parameter which takes an order.
And order just looks like this order with one public property called quantity.
And you might take a look at this order processor here now.
And maybe you think that looks fine right.
Okay.
We got the process order.
And then we have an algorithm here and some logic.
You know I know that this sounds valid okay.
But the thing is that you should instead of write down the entire logic here inside of the process order,
split this up into three separate methods.
You should have one method that handles the validate order logic.
You should have one method that's meant to handle the saving process, and one for the notification
for the customer.
So let's do it.
That way we can say private, we don't have to do it public.
Totally fine.
Private void validate order.
We take order order here.
Then we have the logic here.
Right.
We can add a to do to do uh validate order logic.
Let's just duplicate that and one more time now for save order.
So save order and for notify customer.
Now again we want to do the to do's here.
So notify customer logic.
You just want to do it the correct way and save order logic right.
Totally fine.
For notify customer.
Let's just assume that inside of the order we have a link to the customer.
Right.
This lecture is really about that.
You understand that this looks great, but it should look instead like this.
We validate the order.
Then we save the order and then we notify the customer.
In that way, the entire logic for sure we want to use that order parameter everywhere, right?
In that way, we now have encapsulated the entire logic into separate methods that we can use everywhere
right now.
Don't get me wrong, we can do it like this.
So private bool validate order and then we return false here by default.
Right.
We would have some logic here.
Then we can wrap this into an if statement.
If validate order we can do it that way.
Don't forget what you have learned since it's returning a bool we have to adjust the name.
So right click go to rename.
Let's refactor it.
Let's say is valid.
For example, right now we return a bool and then we can check if it's valid.
And then we see if it's valid safe order and then notify customer.
Right.
But again it's the same.
But the logic of each of those steps is that we need for our code to run or for our program to work
is separated into methods.
This is what you should create, because if you want to use that logic anywhere else, again, saving
an order, you don't have to, uh, duplicate that code following the dry principle, right?
Don't repeat yourself.
We simply create an encapsulated method that handles the logic for saving, that handles the logic for
notification, that handles the logic for checking if something is valid.
Great.
So that looks cleaner.
And whenever you want to use save order again, or you want to adjust that, uh, logic, you don't
have to go to process order to change that.
Instead, if you want to change the algorithm for save order, you go to save order method.
All right.
So keep in mind that whenever you have a process procedure inside of your application, put it into
a method so that you can reuse that method over and over again whenever you need it.
Anywhere else in the code.
That also will increases or improves the maintainability of your code.
And I mean, that's what we are talking about here.
We're talking about clean code.