Don’t make your code smelly

Smelly code is one of the worst nightmares a developer will have when he want to customize / optimize software developed in not best approaches, here the concept of refactoring came to the surface (if the developers follow structural and functional rules) they will make the development cycle easier to understand and cheaper to modify / upgrade without changing its observable behavior.

Poorly designed programs have been created by developers, resulting in applications that are inefficient and hard to maintain and extend. Software developers are discovering just how difficult it is to work with these inherited, non-optimal applications. Using object oriented techniques employed a growing collection of techniques to improve the structural integrity and performance of software development these techniques are referred to as “refactoring”.

In refactoring: improving the design of existing software, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process. He explain these rules in details in “Refactoring: Improving the Design of Existing Code

One of the clear symptoms of object-oriented code is its comparative lack of condiitonal statements. The problem with conditional statements is essentially that of duplication, often we find conditional statements scattered about a program in different places. If we add a new clause to one conditional statement, wehave to find all these statements and change them. The object-oriented notion of polymorphism gives an elegant way to deal with this problem. Most times where conditional statements involved, polymorphism should be considered.

Extract Method should be used to extract the statement value and then move method to get it onto the class where the polymorphism is needed, we changed our code to this because conditional statements check on a type code and we want the method or class that hosts the type code value. Here we need to decide whether to Replace Type Code with Sub-class or Replace Type Code with State/Strategy. When inheritance structure need to be setup, we can Replace Conditional with Polymorphism. If we only have a few cases that affect a single method, and don’t expect them to change, then polymorphism is overkill. In this case we need to Replace Parameter with Explicit Methods is a good option.

“Polymorphism gives you many advantages. The biggest gain occurs when the same set of conditions appears in many places in the program. If you want to add a new type, you have to find and update all of the conditionals. But with subclasses, you just create a new subclass and provide the appropriate methods. Clients of the class don’t need to know about the subclasses, which reduces the dependencies in your system and makes it easier to update” Page 206 Refactoring: Improving the Design of Existing Code

Below example (written in typescript) will show using polymorphism instead of (if …. Else) condition:

Animal Class:
class Animal{
sound: string;
type: string;

constructor(type: string, animalSound: string){
this.sound = animalSound;
this.type = type;
}
}
let sound = '' : string;
let cat = new Animal('cat', 'meow');
let dog = new Animal('dog', 'bark');
let bird = new Animal('bird', 'singing');
let animals = [ cat, dog, bird ];
// Using if ... else
for (let animal of animals) {
if(animal.type === "dog") {
sound = dog.sound;
console.log(sound);
}
else if(animal.type === "cat"){
sound = cat.sound;
console.log(sound);
}
else if(animal.type === "bird"){
sound = bird.sound;
console.log(sound);
}
//becomes this:
for (let animal of animals) {
console.log(animal.sound);
}

}

}

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.