Bad Smell in code Refused Bequeast

This is what the book says about "Refused Bequest"

Subclasses get to inherit the members and data of their parents ( base class). but what if they don't want or need what they are given? they are given all these great gifts and pick just a few to play with.
The traditional story is that this means the hierarchy is wrong. You need to create a new sibling class and use "Push Down" these unused members to the sibling. This way the parent ( base class) holds only what is common. Often you will hear advices that all superclass (base classes) should be abstract.
You'll guess from our snide use of traditional that we are not going to advice this, at least not all the time. We do sub-classing to reuse a bit of behaviors all the time, and we find it is perfectly good way of doing business. There is a smell, we can't deny, but usually it isn't a strong smell. so we say that if the refused bequests is caused confusion and problem, follow the traditional advice. However, don't feel you have to do it all the time. Nine times out of ten this smell is too faint to be worth cleaning.
The smell of refused bequest is much stronger if the subclass is reusing behavior but does not want to support the interface of the supper-class. We don't mind refusing implementations, but refusing interface gets us on our high horses. In this case, however, don't fiddle with the hierarchy; you want to gut it by applying "Replace Inheritance with Delegation.

.
From here, the author identified two bad smells, indicated one is worse than the other. The less sever one is "refusing members from the base class" , the more serve one is "refusing interface from the base class or interface". Let me touch on them in detail in reference to our codebase, less sever one first.


The book says "if refused bequests is caused confusion and problem, follow the traditional advice" so I am going to repeat the advice here: If they cause confusion, push them down to where it should be, create middle level classes if need to. the guidelines on this principle is 1) define one specific business logic or data element only in one place, 2) do not provide members to the class that does not make sense or not needed. I was made to believe some of these subclasses or members are not in use... if so we can safely remove them from our code base.

Refusing interface from the base class or interface

it means if your class implement your own interface, you want to provide implementations for all its members.
if you do not want to implement certain interface, you either throw Not Implemented exception to notify consumers or provide default implementation, or remove the member form the interface.

However, the solution is simple:

1) if the class or a member is no longer in use, take them out, if you are not 100% sure, comment them out or exclude them form the project but keep them in the version control library, in case we want to take them back..
2) if the member in the interface is no longer needed, take it out and talk it out from all it implementations
3) If the public member is no longer needed, take it out and all remove reference to it.
4) For private methods if you might want to put the logic in it later, at least you want to put a todo in it, so that people knows what is going on here.



This is like you live in your own houses, you want to take out the trash regular, you want to do some clean up once a while, you want to put the right thing in the right place once a while. this is so that you will enjoy your living more. Imagining in a house, for years, nobody does these things. There are trash everywhere, stuff are laying down all over the places. empty milk jar, leftover food are in the fridge. Do you enjoy living in the house, can you be productivity in the house? Sure enough, there are times, we are in the hurry, so we leave the dirty dish in the sink and heading out for something urgent. but when we are back home, or in the evening or weekend, we want to clean them up. The same is true, in software development, there are times ( a quick fix before it is released, or must fix a production defect in quickest possible way.) we leave something behind us, but we need to clean them up after the urgent issue is addressed. These are not some rocket science, it has nothing to do with technology. They are some basic practices in software engineering. however, a good deed goes long way down the road. Sometimes it might as important of "make it or break it". in a software development project.

Let's work together to make our project a successful one and a enjoyable one.