Code Smells Part 1

13:20 Divergent Change

In order to make a change in a class you have to make that change in several places within that class. This tends to be a sign of poor software architecture. It is more likely to occur earlier in your career. Experience should provide better architectural design.

Extract out the parts that are changing to another class. Reduces duplication and increases organization. Maintain single responsibility for each class.

15:29 Shotgun Surgery

When changes in one area of code requires changes in multiple other areas think of refactoring. This comes about from over use of single responsibility. The responsibility is broken up into several classes.

“This is the opposite of divergent change and can result from over fixing it.”

Bring the classes together into a single class for each responsibility to provide better organization and easier maintenance. Doing so will reduce replication of functionality in the code.

17:33 Parallel Inheritance Hierarchies

Anytime you create a subclass of one class you have to make one of another you have smells in your code. It’s not a big problem with smaller hierarchies but as classes get added it becomes a nightmare.

Remember that not all smells indicate the worst code, this could be a way around something even worse. If by fixing this you make the code worse revert back to the parallel hierarchies.

Remove the duplication by combining the hierarchies. Make instances of one hierarchy refer to the other then remove the hierarchy in the referred class. This reduces the chance of redundancy and may improve organization.

20:00 Same Class Different Interface

“This is the bane of my existence right now in one of the projects I’m working on.”

Two or more classes that do the same thing but have different interfaces or method names should be investigated as a code smell. This is duplicating functionality within the code.

It usually happens when developers refactor not knowing what one class does or they don’t finish a refactoring. It may also result from too many cooks in the kitchen

“I like to call these bread heel classes.”

Put the interfaces into common terms between the classes. They can then share the interface. You can also make one class a subclass of the other.

22:34 Refused Bequest

When you inherit from a class but don’t use anything from the parent class you should consider refactoring your code. The child class may only use some of the methods and properties. Unnecessary methods are usually unused or redefined meaning exceptions have to be handled.

“A dog and a stool both have four legs but that’s about it.”

This comes about through overuse of inheritance to reuse code but the classes are too different. Inheritance is misused only to combine common code not because child class is an extension of the parent.

Replace the inheritance with delegation. Put the parent class object into a field then delegate the methods used from the parent. If you must inherit take the methods both are using and make them siblings under a new parent.

25:40 Cherry Picking With Temporary Fields

This occurs when objects have a lot of optional fields that are not necessary. These fields tend to only be needed under certain circumstances. Therefore most of the fields will be empty.

Most of the time you’ll find this when an algorithm has many inputs. Instead of sending a bunch of parameters they are added as fields in the class. The data in the fields is empty most of the time.

Pull out the fields into a separate class and use it when calling the algorithm. This creates better clarity and organization of your code.

29:32 Inappropriate Intimacy

Too much intimacy occurs when one class uses the internal fields and methods of another class. It happens when classes spend too much time together or they interface in inappropriate ways. Classes should only know what is necessary about one another.

“It’s a lack of enforcement of boundaries.”

Several solutions exist to this problem depending on the situation. The simplest is to move the parts from one class to the other. Create a relationship hierarchy or inheritance. If they are interdependent change the dependency to unidirectional.

31:18 Indecent Exposure

“Your parts are showing!”

This happens when methods or classes that should not be public are visible. Parts that do not interface with the public are shown. Doing so shows unimportant or indirectly important code. Code is not hidden or improperly hidden.

>Make private methods private and encapsulate classes. This reduces the complexity of the code and protects methods that should be private.

34:10 Feature Envy

This happens when a method uses another class more than it’s own. It accesses the other object’s data more than it’s own or relies on the other class too much.

“A lot of times it’s specific implementations of a class.”

Typically this occurs after fields are moved into a data class. Most of the time things change at the same time. When data is moved the functions on that data are moved.

Move the method to the class it uses most. If only part of the method uses it extract that part and move it. Less redundancy of code functionality and better organization.

36:13 Message Chains

Message chains are long sequences of method calls to get data. You request an object that requests another and another, etc. Multiple temporary variables is the same thing.

“It’s not just about your dependencies on other classes that make things smell it’s like if you are dependant on how two classes relate to each other.”

This means there is a dependency on navigation through the class structure. Any changes require modification of the entire chain. Watch out for intermediaries as they can hide dependencies.

Create a method in the first class to delegate to the subsequent classes. Hide the delegation from the code calling the method. It will be easier to make changes to the program. Be careful as you risk overdoing it and creating unnecessary go-between.

38:03 Middle Man

A middle man appears when a class delegates all it’s work. Either the class has only one function that is delegated or all functions are delegated. It becomes merely a wrapper for other classes.

Most often this happens when the useful work done by the class has been moved to other classes. Overuse of fixing message chains can lead to this. It is an insidious problem as it can occur gradually though. To resolve it remove the middle man.

40:32 Incomplete Class Library

This comes in several forms. You may need a method that is missing from the library or the library stops meeting the needs of the code. Other times the responsibilities of the code should be in a library.

You may be unable or unwilling to modify the library class. The author of library may have not provided or refused to add features you need so methods get tacked on to other classes.

“You can basically use a mediator type pattern to talk to the library.”

If you do not have access to the library class add a method to a class then pass an object of the library to it or create a new class with extension methods that are either child or wrapper methods for the library