The right way to reuse code

In this article, we going to focus on how to reuse code.

Why should we reuse code? Are there exceptions to this rule? Are there side effects when reusing code? Let’s get started.

To make code simpler and less prone to bugs you should reuse code. Probably every beginner programming course talks about that and it’s important. Let’s first talk about the basics and why should we reuse the code and then we will see an exception to the rule that not many people know or think about.

If not for anything else — be selfish. Reusing code means you will write and maintain less code. And the code is more prone to bugs if you have more code. Simple math. Also, when you have duplicated code and you want to change it you need to change it in two or more places. The problem with that is that you might forget to change it in all places and this will cause inconsistencies. Furthermore, this is time-consuming. We know how expensive developers’ time is, so try to save it as much as possible. There are many more problems with duplicated code, but we won’t talk about them. It’s just not a good practice, don’t do it. Or I will find you!

We saw how important is to reuse code, so you should reuse the code as much as possible. Right?

And the exception is…Business logic.

Business logic means an actual business case. Which means the actual functionality of the product you are working on. For example: ”When you write something in the search bar and click search — results for the search are shown” — this is a business case. When we have a business code, which we often have, we should be very careful. I’m not saying don’t reuse it, I’m saying be cautious.

Let’s see a very simple example that will show you that sometimes it is not a good idea to reuse code and might make our system fragile.

We have an Employee class with two fields in it. One will represent the employee’s monthly salary and the other will represent the monthly table tennis wins(since we have a table tennis tournament in the company). These are two very different things, right?

We have a Reporting class and a method in it that calculates the sum of all the salaries the employee received.

It’s a simple method that sums all salaries and returns it. Here is a stream version of it(I know not all people know Java streams):

Now we need to develop a new feature, a new business case. We need to generate a report with all the monthly table tennis wins for an employee. Since we know that we always need to reuse the code we reuse the same method. It’s very convenient, right…Now imagine that: there is a tax increase and we need to increase the employee’s salaries by 5%.

There are two possible things that might happen:

You see that reusing business logic often is not a good idea, and you need to be careful about it. Business logic tense to change. Just keep that in mind and think twice when you have to reuse business logic. Sometimes it is okay but depends on the case. If you work in a company and you have a Product Owner(this is a person that is responsible for the business logic), you can ask him or her if the feature you are working on might change. But even if they told you that it will not, be careful. The clients do not always know what they want.

I know that my example is a little silly and stupid, but I need you to get the abstract idea from it, don’t get caught in the concrete example.

The answer is — in all other cases. If you have a logic, algorithm, or something that you know won’t change — reuse it. Even if you know that something might change, ask yourself — will the change need to happen in all the places that you are reusing this code? If yes, then reuse it. Imagine having an Employee and a HourlyEmployee class. Then if you have a method for calculating the sum of all the salaries for an employee, it’s totally okay to reuse it. The two objects are very similar and if there is a, let’s say, tax increase — it should happen on both Employee and HourlyEmployee classes.

If you loved this article, you will love our course on Clean code

Related posts:

Il lavoratore era stato “disconnesso” dopo essere diventato un sindacalista molto attivo, avvicinandosi alla Nidil Cgil e rilasciando dichiarazioni alla stampa locale. Ha presentato un ricorso al…