When does class inheritance hurt you later?

Question

Can you provide scripts when we inherit the class, it works for a while, but then something else changes and introduces an error? I came up with the following situation:

• to implement Rectangle-with-hole, we inherit the Rectangle class. In the constructor, we check that the hole is inside the rectangle
• Later, someone adds a new Resize method to the Rectangle class. They do not check if the hole is inside.
• After resizing, we can have rectangles with holes with holes inside the rectangles, which is a mistake.

What are the other problems, I have to be careful if I want to use object inheritance in C #.

Answer 1

There are many ways in which changing a base class can affect the behavior of a derived class. What if the author suddenly decided to make a sealed class for example?

Like any interface, it should be stable if consumers do not need modification.

The main “rule” with inheritance is the Liskov Signature Principle. This means that the derived class must be replaced for the base class or other classes derived from it.

This case violates this rule on his face, because the rectangle with the hole is not a rectangle.

It is usually best to use interfaces to divide behavior into reasonable implementable chunks. Such interfaces are usually called adjectives, not nouns. For example, this makes sense for both a rectangle and a rectangle with a hole for display, so the interface can be IRenderable . If it is changed, you may have IResizable , etc. They can be combined in IShape , but you want to be careful that your Shape definition only defines the behavior of your problem domain.

Deriving directly from another class can be dangerous, since you are then bound by the behavior of that class. If you really need to do this, it is best to extract the required implementation into a common base class (e.g. Rectangle : RectangleImplementation, IShape ).

Answer 2

What you describe is one of the traps of inheritance.

Another mistake is the deep hierarchy of inheritance. Stackoverflow thread on composition over inheritance .

Answer 3

This is called the fragile base class problem .

Another potential problem with inheritance in general is that you would like to use your own base class, but the infrastructure requires a specific base class (e.g. ContextBoundObject ) instead of an interface.

Answer 4

This is why C # forerunners added a private keyword to the language. Use wisely.

And use code contracts to test your invariants to get an early breakdown warning.

Answer 5

Do not call the virtual method in the constructor. See Eric Lippert's Messages on this ( part 1 and part 2 ).

Answer 6

It is better to use -Decorator Pattern in these cases. This provides a better way to expand.

This can be implemented using the following diagram:

A rectangle object will be created and wrapped in a HoleDecorator object, which will be responsible for providing the hole. When the rectangle is resized, the HoleDecorator will be resized, it will first call the Resize of Rectangle and then call AddBehavior for the Decorator of the hole, which will indicate what to do with the hole when the main component is resized.

Answer 7

I think this is not related to C # or inheritance. No matter what you do, this is an unavoidable software development issue.

The best and easiest solution: create your code daily and do unit testing .