Extract Method refactoring is a great way to give names to concepts so code is easier to read and flows. But it can go wrong when you use it, creating a lot of indirection and unexpected behavior from the methods you extract.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
I want to dive into a topic that’s been on my mind: refactoring, specifically the “Extract Method” technique.
TLDR: I’d rather read a longer method—maybe around 50 lines—than get tangled up in a web of indirection caused by overusing “Extract Method.” So, let’s walk through an example that illustrates why this is the case.
Code Example
Let’s jump into our example, which revolves around a user signup process for a chat system.
The first step is checking whether the username has been specified. If not, we throw an error.
Next, we check if a user with the same username already exists in our system. If they do, we also check if they’ve been activated yet—meaning their activation date is null. If the email address tied to the username is the same, we assume it’s the same user and prompt them to activate their account. If there’s an existing user but with a different email, we notify that the username is already registered.
Then, we create a new user object and check for channels that require users to be 18 years or older. If the user isn’t 18, we filter out those channels and reset the channels they can access. Finally, we save the user and send them a welcome email with an activation link.
Extract Method: The Good and the Bad
Now, “Extract Method” could help us break this down, but it can also complicate things. For instance, we might start by extracting our conditional statement for validating the username, naming it something like ValidateUsername. That’s a decent start, right?
But as we go deeper, we might extract other conditions, like checking if the user is already registered but not activated. We could call that ExistingSignUpNotActivated. This seems okay at first, but here’s where it gets tricky. At a glance, looking at our entry point now means we have to navigate through multiple methods to understand what’s really happening.
The problem is that when you have a lot of indirection—like calling one method that calls another—you lose the clarity of the original logic. It becomes a bit of a maze.
Issues with Overusing Extract Method
One major issue is that the entry points don’t make it clear what exceptions might be thrown. For example, when we call ValidateUsername or ExistingSignUpNotActivated, we don’t inherently know they throw exceptions unless we dive into the method details. This can lead to confusion, especially if we’re making changes that could affect those calls.
Another issue is the indirection itself. If we end up with multiple levels of calls, it becomes hard to track what’s happening. When you start adding more methods, it feels like you’re just jumping around trying to piece together the logic.
For instance, when we check for age-restricted channels, we might extract that logic into filterAgeRestrictedChannels. But now I have to go find this method to see what it changes—it’s not just returning a value, it’s modifying the existing channel list. This isn’t obvious at first glance.
Guidelines for a Better Approach
So, what does a better approach look like? Instead of mutating state within methods, I prefer to return values. For example, if FilterAgeRestrictedChannels simply returns a new list rather than modifying the existing one, it makes things clearer and easier to follow.
Also, when naming methods, I strive for names that clearly indicate their intent. This way, the code reads more like a book and less like a mystery novel. By keeping methods focused and avoiding side effects, we can maintain clarity.
In my revised version, I wouldn’t want sending an email to throw exceptions in the middle of the user creation flow. Instead, I’d handle sending the email as a separate thread/process, asynchronously, that is triggered by the UserSignedUp event.
Extract Method Refactoring
“Extract Method” refactoring can be a valuable tool. Sometimes, the clarity of a longer method is preferable to a fragmented one filled with layers of indirection. I’d much rather read those initial 50 lines than get lost in a rats nets of method calls and exceptions.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.