Method Refactoring

[info]bpfurtado has raised an important question concerning some odd practices in software programming. People who code applying the same paradigm to all computer languages, thinking the only difference between programming languages are all about their syntax and grammar. These kind of code generate a lot of bad consequences, like the one I will focus at this post.

Sometimes I see people writing methods like “doX&Y&Z”, reflecting more than one responsability inside a method. Clearly this kind of design isn’t focused on reuse and maintenance, because people who code this way don’t even know such practices, characterized in OO programming. Methods must be cohesive, that is, “a cohesive method is responsible for one and only one well-defined logical task”.

Such a method could be factored into three little private methods, named “doX”, “doY” and “doZ”. To one public method is given the responsability to coordinate the tasks between the three methods. Talking about the former approach, how can you reuse one of the computation inside the “big” method? It’s impossible. So, reuse and maintenability is better achieved in the latter approach.

It occurs that people start programming in a language without knowing the paradigm it applies. So, people need to change their mind to produce better code, otherwise real big projects will continue to suffer the same problems we are tired of hearing nowadays.

2 Replies to “Method Refactoring”

  1. Good post about refactoring and good design of separating responsabilities among the methods of a class!
    “doX&Y&Z” is indeed not the best name to some method, but if inside of it you have refactored the three tasks X, Y and Z into three separate methods, that’s not all bad 🙂
    And since the old times of 2003 when I met the first real java IDE, the IntelliJ IDEA, that there’s no excuse not to “Extract Methods”, and nowadays Eclipse handle this simple refactoring also for years (even Netbeans does that ;).

  2. Good post about refactoring and good design of separating responsabilities among the methods of a class!

    “doX&Y&Z” is indeed not the best name to some method, but if inside of it you have refactored the three tasks X, Y and Z into three separate methods, that’s not all bad 🙂

    And since the old times of 2003 when I met the first real java IDE, the IntelliJ IDEA, that there’s no excuse not to “Extract Methods”, and nowadays Eclipse handle this simple refactoring also for years (even Netbeans does that ;).

Leave a Reply

Your email address will not be published. Required fields are marked *