Tag Archives: object oriented

The tremendous power of tiny refactorings

More and more I am being intrigued by the power of a small code refactorings. The positive impact it has on the readability, the maintainability and understandability of your code is great. It keeps code clean(er) and since the changes you make are really small (I’ll demonstrate how small), the chance they will break things is small. Of course, with unit tests (you are writing them right?) making sure you did not break anything: a small refactoring is a low-risk high-benefit practice.

In my experience, small refactorings are undervalued. In fact, I undervalued them much myself since not too long ago. They are disregarded as refactorings that don’t help at all, because it is obvious what the code does. However, the flaw in this rationale, as I see it, is that the intended audience is not only you but also the other developer you work with. Also, you know what code does right now. But would you understand it as quickly if you did not look at it for a week and came back? Would another developer understand the code right away?

When working on code, you’re constantly trying to ‘translate’ the code in your mind in order to know what it is doing. Doing this it leads you to where the bugs are or the areas where you need to make changes, etcetera. This process of ‘translating’ code in your mind comes at a price. Literally the energy you need to burn in your brain to grasp the meaning of a piece of code: brainpower; The easier we understand code, the less brainpower we need. The less energy we burn by understanding what is going on, the more energy we have left to create new things, or fix that bug.

I’ve created a little example. The code below represents an implementation of a mail service. The mail service allows you to send an email using a method that uses 4 parameters: to, from, the subject and the message. When all parameters are filled, the email needs to be sent. That is the only requirement for now. Of course, later we might want to validate if the given email adress of from and to are valid. But for the sake of the argument, lets keep it simple. The following code is ‘mind-boggling’, compared to its simple intention:

[sourcecode language=”java”]
public class MailServiceImpl implements MailService {

public void sendMail(String from, String to, String subject, String message) {
if (from != null && !"".equals(from) &&
to != null && !"".equals(to) &&
subject != null && !"".equals(subject) &&
message != null && !"".equals(subject)) {
// send the email
}
}

}
[/sourcecode]

Basically what this says it that any field may not be null or an empty string. It took 4 lines for just to show. Even though you recognize the pattern of a ‘null or empty check’, it costs you time and energy to make that translation happen. So here is a first suggestion to make it read easier:

[sourcecode language=”java”]
public class MailServiceImpl implements MailService {

public void sendMail(String from, String to, String subject, String message) {
if (parametersAreNotNullOrEmpty(from, to, subject, message)) {
// send the email
}
}

private boolean parametersAreNotNullOrEmpty(String from, String to, String subject,
String message) {
return from != null && !"".equals(from) &&
to != null && !"".equals(to) &&
subject != null && !"".equals(subject) &&
message != null && !"".equals(subject);
}

}
[/sourcecode]

When another developer is reading the sendMail method, he will now know that when the parametersAreNotNullOrEmpty the mail will be sent. It does not need any translation, the method name just says what it does! Simple! By doing this, you greatly reduce the needed brainpower to understand what is going on. The refactoring method used is called Extract method.

Reading code is sometimes easy for your brain to handle. Sometimes your brain seems to explode because of the complex statements and context you need to be aware of. It is strongly tied with the Cyclomatic Complexity, the Coupling between Objects (CBO) and the lack of Cohesion in your code. If you are using any tools to measure your code, like Sonar for example, look for these metrics to find code that needs attention. But it is always better to refactor while you have made the translation in your brain, if you see things can be written simpler to reduce the needed brainpower, by all means do so. Not giving software the appropriate attention might let your code rot. Small refactorings help you prevent that.

I hope you have seen a bit of the power of small refactorings. I will get back to them in my future posts as I will post more concrete examples and how I would/have dealt with them. To me, small refactorings need to be part of your system and are introduced when you do TDD. All too often when the code works, it is not looked at again. Making these small refactorings can make a big difference and take relatively no time.

Overriding and methods

Today I had a little challenge. I had a Class, I call it Class A. It has a method, i call it “doSomething”. Class B extends Class A, and overrides this method with a totally new behavior. Class C who extends from Class B wants to have the original behavior from Class A.

Here is a picture:

The Problem

Now, the simplest but most stupid way to solve this is using copy / paste. Yes, you simply copy the contents of the method of Class A and paste it into the method of Class C and you’re all set right?

Wrong!

It might work for a while, but one of the first things you *should* be feel itchy about, is code duplication! (along with its problems you get when you want to maintain your code).

So what now?

Solution : Use method for shared behavior

Solution : Use method for shared behavior

Well, when you took the easy road and duplicated your code, you probably wanted to get rid of that duplicate code immidiatly… And how do you do that? .. Yes,  you create a new method which is put in Class A , and accessible from Class C and Bam! Code Duplication gone, and you got what you want…

Another way is to re-think your class hierarchy. You might want to consider to do this:

 

Solution : Change in hierarchy, extend C from A, B from C

Solution : Change in hierarchy, extend C from A, B from C

 

 

Yes, you’ve seen it right. Perhaps you can swap Class B and C.  So C extends now from A, and B from C.

But, if you do that, be careful. You need to know exactly what kind of behavior you wanted in Class B. Most likely you have changed that now by extending from C. Take a good look at what methods B was originally calling from Class A, and if it now calls an overridden method by Class C.

These 2 solutions came up today. For my particular problem I’ve used the first. (no, not copy paste smart ass)

I think the first solution is the easiest, I would not recommend anyone to do the second solution unless you really know what you are doing. If you encounter more of these problems like above, swapping might be better for you.  

Do you got another (better?) solution? Let me know!