If an entity of the business changes its name, should there be a refactoring?

Question

This question comes when there are changes during development and some entity of the business changes its name or its purpose. When it comes the time to develop, it can get very confusing during meetings, development, or any process that you mention that entity that has just changed.

Suppose we're in a business of plastic cups, so we create everything over that name. But for some reason, there are not plastic cups anymore, there are glasses, they work different from plastic cups, but not so different. In code, there should be a refactor of names? Or is it better to create a new object? Or better not to do a thing?

Does this code should change like this? :

public class mainClass(){
    private PlasticCup fullCup;

    public PlasticCup createNewCup(){
        fullCup = new PlasticCup();

        return fullCup;
    }
}

To:

public class mainClass(){
    private Glass fullGlass;

    public Glass createNewGlass(){
        fullGlass = new Glass();

        return fullGlass;
    }
}

Answer 1

This depends heavily on the circumstances, and on factors like

• How many people work with that code, actually come in contact with such internal names, and get potentially confused when the name is changed, or might get confused in the future when the name is not changed?

• How different are the meanings of the old name and the new one really?

• How much work will the actual renaming really cause. This depends on further things like how much code exists which relies on that name, how powerful are the available refactoring tools, and necessary changes to documentation, extra testing and debugging efforts.

• Are there persisted entities with the old name which must correspond to the class name in code because of the used persistence technology? Will you have to support them for backwards compatibility? How costly is a conversion of those persisted entities?

• Is it really just a name change, or also behavioural change, where the new behaviour does not really fit any more to the old name?

• What is the expected life time of the code which contains this name? If it is expected to live for decades, a renaming is probably more benefitial than for code which is only expected to be used until next quarter.

• Is there a more general name, which may cover the meaning of the old as well as the meaning of the new entity in a conclusive way?

In the end, it is a trade-off. One has to make a cost-benefit analysis, taking all those bullet points into account and then make a decision.

Answer 2

This answer is touching on things mentioned in other answers, but I wanted to explain it in a way I find easier to understand.

---

There is a huge difference between data and logic. Data is much more easily changeable than logic. Almost by definition, data is something that can change without requiring redevelopment, whereas changes to logic always need some kind of development effort.

However, when you have data alongside your logic, you have to integrate your logic to use that data. Developing logic that handles data takes a non-zero amount of effort. If the data in question doesn't change, then there's no real point to abstracting it as data. In such a case, we hardcode the information in the logic. It's the least-effort approach.

And don't get me wrong, that's not inherently bad to do. Some thing simply don't need to be abstracted. If we abstracted literally everything that could be abstracted, we'd have countless more layers of abstractions in any codebase, without really adding value to that codebase.
There should only be as many abstractions as you need; not as many as you can implement.

Take the example of a bible salesman. They only sell bibles, no other books, and therefore the "bible" concept can be hardcoded in this bible salesman's codebase:

public void SellBibleTo(Customer c) { ... }

This is perfectly fine as long as they only sell bibles.

But just like in your situation, that rigidity has ceased to exist when this salesman begins selling other books as well. At this point, the code needs to be re-evaluated to account for a much more abstract approach: the ability to sell any kind of book.

It is at this point that the hardcoded needs to disappear, and we need to introduce actual data (including handling) that allows for different values to be used, in this case books.

The codebase will end up with another layer of abstraction:

public class Book { ... }

public void SellTo(Customer c, Book b) { ... }

This is more than just a rename. That's the most important thing to take away from this.

Now, your code can no longer assume that it innately knows which book is being sold, and thus the choice of book becomes an input parameter to your book-handling (previously bible-handling) logic.

---

Moving back to your example, the issue with your approach is that you are merely attempting to rename your logic rather than expand the logic itself.

If your client has decided to also handle glasses instead of just cups, it becomes clear to see that products can change. It's highly likely that your client is going to handle a third, fourth, fifth, ... kind of product down the line.

When things need to be able to change, they are data that can no longer be hardcoded. Therefore, just like how we needed to expand our example logic to handle any kind of book, now we need to rewrite the logic to handle any kind of product. I'm calling it a "product" for lack of a better name, I don't know your company's market focus.

I was going to refactor your code example but it's not a particularly meaningful one to rewrite since you're only using a hardcoded parameterless constructor in a factory whose name doesn't describe its purpose.

So I'm going to create my own example here. If your old code was this:

public void ShipCupToCustomer(Customer customer)
{
    var cup = new Cup();

    washer.Rinse(cup);
    
    var box = packer.Package(cup);
    
    labeler.Label(box, customer.Address);

    shipper.Ship(box);
}

Then your new code would be something along the lines of:

public abstract class Product { }

public class Cup : Product { }

public class Glass : Product { }

public void ShipProductToCustomer(Product product, Customer customer)
{
    washer.Rinse(product);
    
    var box = packer.Package(product);
    
    labeler.Label(box, customer.Address);

    shipper.Ship(box);
}

It's not a huge change, but it is an extra level of abstraction.

Note that this will also cause you to have to change the washer and packer objects' interfaces to account for all Product types, but this example is meant to be short and simple.

---

Being able to spot this trend early is going to enable you to be prepared when it does eventually happen. It's okay that you didn't spot it during the first version, but now that you have direct experience with this kind of thing happening, you should respond to it accordingly.

Answer 3

I think you should not avoid the renaming because - as you already experienced - this can lead to a lot of confusion. Your example is of course very significant so based on the real situation a simple renaming might not be enough. A glass will have different characteristics as opposed to a plastic cup.

But in case it is only the name of some business entity which is changing due to changing business terms I would invest in rename refactorings which can be very simple if you have a good IDE (option A).

If there is more to change as I would assume of the plastic cup to glass evolution I would first grab a whiteboard and find all similarities of the two entities. Then I would refactor in several steps by first trying to refactor common stuff into maybe some new value objects (if that has not happened already) or even some new entities which are common to both plastic cup and glass.

This makes it easier to do both either refactor the existing plastic cup (option B) entity which also includes renaming of the entity. Or introduce a new glass entity (option C) which will use the same common stuff. And later on you could sunset the old plastic cup entity altogether.

Option B makes sense if plastic cup and glass do not differentiate from each other that much. Option C makes more sense if they only share some stuff but still have significant logic differences which need to be added as new code anyways.

Note: I would only invest the effort (either option A, B, C) if the business has come to a well thought decision and something like this happens very rarely. In addition, the efforts for the change in the code (and potentially other depending modules) with the avoidance of communication problems and confusion betweeen development team and business people have to be weighed out against sparing the effort but changing code but being faced with confusion and inconsistencies between requirements, domain concepts and the actual implementation.

Answer 4

Separate the things that change from the things that stay the same.

Suppose we're in a business of plastic cups, so we create everything over that name. But for some reason, there are not plastic cups anymore, there are glasses,

At this point it's a distinction without a difference. All you've shown is that the name should have been more abstract.

they work different from plastic cups

But here you show a need for a new class with a new name if for no better reason than to avoid destroying old tested proven plastic cup code. Even if you know you'll never make a new plastic cup again, which you don't, having the original code under the original name is less confusing as you convert to the new one.

but not so different

And here you show a need to factor out common behavior in a third class. If you feel that’s too much then just forget OOP and write some procedural if structures.

One of the signs of good code is code that’s easy to change. Do what makes it easy to change.

Answer 5

This is tricky. Let’s say your company has a “support” department. Everyone knows what you are talking about when you talk about “support”. So the name has entered your code base, like in a method called “sendEmailToSupport”. And now the company changes the department name to “complaints”.

You’ll have to make code changes. Like some code will now send an email to “complaints@company.com” etc. That’s needed, and it’s not refactoring.

What about that method “sendEmailToSupport”? I’d suggest refactoring it. It’s not urgent. Do it when “complaints” has some foothold in the company. Do not wait two years until nobody remembers what “support” means and why that email method has such a weird name. (Obviously “refactoring” means changing names and comments, nothing else).

Answer 6

What's the real problem?

Considering your comments, it appears that the naming change is not necessarily related to a product change:

• If you reuse the same code and adapt it to different companies, keeping the name of the company in your code is not an option (risk of confusion in your team, risk of customer disappointments if customer gets access to code base). You'll have to change the class-names, but also some class behaviors. You might end up with two distinct code bases that will be difficult to keep in synch.
• If you reuse the same code and adapt it to different products, you'll need to take care for specific product characteristics and behaviors. Cloning the class and adapting it will produce redundant code difficult to synch. Modifying the original code will loose your old, verified and proven code to get a new one. You might then as well end up with multiple clones of your initial product classes.
• If you have the two cases, it's two times the problems above :-)

What name for what abstraction?

In our daily language, diffrent concepts have different names. And when different concepts share the same name, it's always ambiguity guaranteed. It's not different for your code.

• If you have a very general Product class that is reusable for all companies and all product lines, give it a very general name. Don't give different names to the same thing. DRY.

• If you have product-specific or company-specific characteristics and behaviors, it is worth to reengineer your code base to express in the code the generalisation of the common characteristics and behaviors on one side, and the specialization of those in the code.

A different name would then mean a different concept. ANd anew product line would always mean a new class. Of course, this is a real design effort. But it's worth it in most cases:

• what you have developed and tested for the general Product will continue to work, whatever the product line or the company.
• the separation of concerns will moreover help you to maintain a synchronized code base for the general parts: If you correct a bug on the general behavior, all the specialized versions will benefit from it too.
• if further adaptations are needed, you'll benefit from an easy reuse of your code base.

Remark/edit

I've edited my answer in view of your comment. For the records, intially I pointed out that, having worked with both plastic and glass industry and reused solutions across branches, the shift from plastics to a glass production seemed to imply much more than the naming change, since these business areas use very different product characteristics, production processes, skills and machines.

I also pointed out that if the change appeared so easy from a company perspective, it was probably because production was subcontracted, which implies that many more such changes should be expected.

I then concluded that your software should reflet raw material or product line in the name of the classes only if it mattered for the feature of your software, and suggested that if the name was kept in line with the product line requirements (concepts), a new product line would require an additional name and refactoring to isolate the common part. It's basically the same approach than here, but explained from a different angle.

Answer 7

Naming conventions are often enforced by the legal department. This usually happens after a company acquisition. Renaming is then done as part of rebranding process (I assume this is related to trademark law).

That decision can't be reasoned about in technical terms. Please consult them, instead of asking the engineering team.

For this reason, as a software engineer, you want to avoid including brands in any names unless absolutely necessary.

From a technical standpoint, rename has a minor advantage of consistent naming down the line, but the damage outweighs the benefit.