DZone
DevOps Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > Legacy Code to Testable Code #6: Add Overload

Legacy Code to Testable Code #6: Add Overload

Gil Zilberfeld user avatar by
Gil Zilberfeld
·
Nov. 13, 14 · DevOps Zone · Interview
Like (0)
Save
Tweet
4.92K Views

Join the DZone community and get the full member experience.

Join For Free

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier. 

In the last post, I’ve talked about Extract Class, and that sometimes in order to do that, we might want to change the signature of a method.

Turns out adding an overload helps in other cases as well.

We used a "setter" to expose and inject internal state before. Another option is to add a controllable overload to bypass the internal state.
Let's look at this code:

public Bool isSameStreet(String newStreet)     {
    return newStreet == this.currentAddress.getStreet();
}

In this example, we compare an external value to an internal state. As we saw before, the option we could use is add a "setter" accessor, to allow injecting the internal value from outside. Instead, we can also add an overload:

public Bool isSameStreet(String newStreet)     {
    return isSameStreet(newStreet, this.currentAddress.getStreet());
}
public Bool isSameStreet(String newStreet, String currentStreet)     {
    return newStreet == currentStreet();
}

We do the actual comparison on the new overload. The new overload should be accessible to the test, depending on language (so it doesn't have to be completely public). In the original method, we delegate the call to the new implementation.

The new overload is more controllable. We can stop there, but if our logic code does not rely on state anymore, why not use Extract Class?

public Bool isSameStreet(String newStreet)     {
    return StreetValidator.areEqual(newStreet, this.currentAddress.getStreet());
}

The StreetValidator class can now be controlled and tested easily.

Time to wrap up the series. So next time, in the last chapter – using dependency injection framework.


Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Migrating Legacy Applications and Services to Low Code
  • Monolith vs Microservices Architecture: To Split or Not to Split?
  • Is Your Code DRY or WET?
  • Top 7 Features in Jakarta EE 10 Release

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo