While a well implemented Objected Oriented code is a hallmark of a good program, a poor implementation of the same could lead to utter chaos as the project progresses. Object Oriented Abusers are a particular genre of Code Smells which refers to incorrect or incomplete implementation of Object Oriented Concepts.
Switch Statements
Switch Statements are something we are used to, it makes writing code faster. But does it make it easier to maintain ? Not really, in fact, switch is almost similar to if-else conditions, just that it is slightly more readable. Another issue with the Switch Statements (or for that matter the if-else conditions) is that it tend to mix logic and data together, which isn’t exactly the best way to do it. We would ideally want to separate the two, so that we can change them independently without interfering with each other. Each time the developer needs to change the logic or the data, he has a mess in his hands. Furthermore it is a violation of Open Closed Principle each time the developer needs to modify the cases to accommodate a new condition (or remove a condition).
The most frequent approach to solve this problem is known as Replace Conditional With Polymorphism, typically done using the Strategy Pattern. Variants of same, namely, Replace Type Code with SubClasses and Replace Type Code with State/Strategy can also be used. There could be situation where there aren’t too many conditions and all of them call the same method with different parameter. In this scenario, polymorphism just might be an overkill and better approach would be a Replace Parameter with Explicit Methods.
A special case that need consideration would be if one of the conditional options is null, wherein you could introduce the Null Pattern or Introduce Null Object.
Temporary Fields
There are times the developer decides to introduce Fields in the Class which are used only by one Method, instead of passing it as method parameter to avoid Long Parameter List. These fields sit idle in the class at all time, except when the particular method is used.
The way to tackle this particular type of code smell is using a variant of Replace Method with Method Object, ie, moving the entire method and its related field to a separate class. It would make your code much cleaner.
Refused Bequest
Another form of object oriented abuse, particularly inheritance, can be seen in derived classes, which doesn’t use most of the functionalities of the SuperClass. In fact, the SuperClass and SubClass is quite different form each other. These inevitably violates the Liskov Substition Principle. Consider the following example
public class BaseClass
{
public virtual void MethodA()
{
Console.WriteLine("Do Something Usefull");
}
}
public class SubClass:BaseClass
{
public override void MethodA()
{
Console.WriteLine("Do Something More Usefull");
}
}
The above code is an example of Refused Bequest. The Child Class ignores the functionalities of Base Class (Refuses to implement SuperClass behavior) and Overrides it. Furthermore, This will also violate the Liskov Substitution Principle as the Inherited class cannot replace the BaseClass in a code without affecting the functionality.
The solution for this particular Code Smell lies on two different approaches, depending on the need of code. There might be a scenario where the Inheritance makes sense to a certain extend, despite symptoms of Refused Bequest, for example, it applies only to limited methods and data fields of super class. In such a scenario, Push Down Method would be one of the refactoring technique you could opt for. Push Down Method recommends to move the method completely to the Sub Class as none of the sub classes uses the functionality provided by the Base or Super Class. The solution with Push Down Method applied would look similar to code below.
public class BaseClass
{
// Other used methods
}
public class SubClass:BaseClass
{
public override void Method()
{
Console.WriteLine("Do Something More Usefull");
}
}
A closely related technique would be Extract Super Class.
In certain other scenarios, the inheritance might seems purely superficial and the best approach would be to get rid of inheritance. That’s where Replace Inheritance with Delegation comes into picture.
Replace Inheritance with Delegation as the names suggests opposes the usage of inheritance when it seems like it is unwanted. This approach suggests us to use an instance of the BaseClass and delegate the functionality to the instance, especially in scenarios when the Sub Class doesn’t require all the methods and data of the Base Class.
Alternative Classes with Different Interface
The last type of Object Oriented Abusers we would be inspecting is known as Alternative Classes with Different Interfaces, which hints at a situation wherein two different classes seems to perform similar responsibilities, but have different interfaces (different method names, signature etc).
Such situation arises mostly when there is lack of communication between team members who end up developing similar classes, or when the developer fails to check the available classes.
The ideal approach towards treating this particular variant of Code Smell is by Renaming Methods or Moving Methods so that both classes end up implement the same interface. There would be other times when only a part of the classes are similar, leading to usage of Extract SuperClass.
Like this:
Like Loading...
Related
ByteLanguage.Net 
One thought on “Code Smells : Object Oriented Abusers”