Extract to Method

[00:00:00]
>> Now extract to method. You have this nested logic here, what do we do? Well, we just take this and we extract it to a method. Not only that is we can safely do this without breaking the enclosing code. Now I have not only do I have three methods now, that I can test, I have three methods I can reuse.

[00:00:32]
This is huge, that what am I doing here now, I'm managing state flow control and more importantly is a managing code volume. And here, I think we probably can figure out what to do here. When you're breaking the single responsibility principle. What do you do? You just extract it to a method.

[00:00:54]
Now, let me make one statement here that you're going to see or one thing that mentally I kind of add a hitch that, what we have here is at the bottom, we have four methods. And they're very, very specific. They take some input, and they return something. And so these have referential transparency is that you're going to call them and you're going to get the same thing every single time.

[00:01:26]
The top two methods. These are what I would call air traffic control methods or sequencing methods. And so if somebody said okay, well, I see here that you're making two assignment statements in this top method. Are you doing two things? Well, I would say at this top level, is that it takes a course in a mode, and it says the appropriate values.

[00:01:52]
And so all this is doing right here. The top method, is just coordinating, the delegation to these lower level functions. If you look at update courses all this is doing is taking a parameters and delegating to lower level functions. It's not actually doing anything other than saying, what did you send me based on this we need to do this.

[00:02:19]
And so now when you look at this, the bottom four methods, you can put something in and you can test the output. You can say, when I want to delete a course, I can test this by I'm gonna put a course in or a collection of courses and the course I want to delete.

[00:02:44]
And then I expect that whatever is coming back is going to be that collection minus that course. And so this is very easy to test. So these bottom four methods, inputs, outputs, it's very easy to write assertions on those for air traffic style methods, what I test on these is that it's delegating properly.

[00:03:08]
So for instance update course, how I would test that is when I pass in my parameters based on the mode I would expect either create course, update course or delete course, to be called. And so just a little commentary on, I think there's kind of sometimes some confusion that somebody could, and you could test the output of these air traffic controller methods.

[00:03:38]
But typically what I really care about Is that Is it calling the underlying methods correctly is this method delegating properly. And so now, what this allows us to do is have fine-grained code over coarse-grained code. And so you always want to move your code Into a state of being fine grained.

[00:04:05]
And so we've taken this, which I would say is very coarse-grained, it's doing a lot of things. And so when you even just mentally look at this, you're already having to kind of create these mental kind of containers and say it does this or this or this. And Then instead we moved to this where we now have fine-grain green code.

[00:04:33]
At the bottom we have four functions that are very specific. We know what they do. They create a course, update, total costs, update course, update courses and this is a lot easier to not only test and manage but to make sense of, and this is really, really important.

[00:04:59]
And so when we talk about complexity, we're not only talking about code and the technical cost. But I wanna be very clear that I'm talking about also the human cost of writing complex code, is that we have better things to do than sit and be miserable, slaving over or languishing in a code base that we can't make sense of.

[00:05:30]
Unfortunately, I admit that a lot of those injuries are self inflicted, because I'm trying to make sense of a codebase that I myself created three months ago or three days ago, and I can't make sense of it. And so, not only am I talking about technical complexity, but managing the the human cost for addressing this complexity is that when you write code like this, it's a lot easier to be successful, be effective and then move on to the things in your life.

[00:06:08]
That you like to do, whether that's playing beach volleyball, pistol whip on VR, eating birthday cake, ice cream, whatever it is. That's, I want you to do more of that and less time fighting with complexity. So with that said, what this looks like in a very specific concrete example and so, one of the questions was around like complicated services.

[00:06:39]
Well, this is what you want to move towards. So this is a facade, which is kind of an Angular mechanism. But this applies to anything is that you want your methods and the logic in your code to be very, very small. And so I believe, if you read clean code, Robert C Martin talks about 20 lines is kind of that threshold.

[00:07:07]
Honestly, I'm typically unless I'm dealing with a very specific piece of business logic that I try to stay really within three to eight lines. Like it's a really command command done and you're constantly delegating or moving this complexity, away from the point of contact, which is the component layer.