Base-Class implementation considerations

Question

I wrote a class to do something and after a while I found that many other classes share the functionality so decided to implement a base-class (abstract in C#) and put all shared into it.

Since it's not possible to instantiate such a class then how to debug it ?

Is there any practical considerations for developing base-classes ?

Answer 1

Debugging the abstract class

There is nothing preventing you from debugging the abstract class, when debugging your child classes the debugger will automatically redirect you to parent class's implementation as required.

Designing class hierarchies

Although simple to inherit in .NET, it can quickly become difficult to maintain if you don't have a clear class hierarchy.

Inheritance is not the only way to ensure re-use in OO.

A couple of recommendations that might help:

• Make sure your bases classes have a clear responsibility
• Keep the depth of your inheritance low.
• Tend to favour composition over inheritance. (Using interfaces might be a good choice)

Answer 2

If you need to test it, you can do one of two things:

1) You can have base classes that are not abstract, so the base can be instantiated and therefore tested.

2) In your test project you can make a mock wrapper around the base and test the mock.

Answer 3

Since it's not possible to instantiate such a class then how to debug it ?

If you are asking how to actually test it then (i.e. Unit Test), I usually write a test class that inherits from the base class and test it that way. If you are asking about actually debugging then it is no different than any other class once you have instantiated it with a child class in a running application. Does that make sense?

Is there any practical considerations for developing base-classes ?

Over the years I've heard two schools of though on this: 1) anything common put into a base class and 2) Don't make a base class if it is not a true inheritance. I tend to design/code to the former but #2 does have its merits in that it can make a design counter intuitive to some extent. Just my $0.02...

Answer 4

I would make a mock object that you make to inherit from your new abstract. You could even use a mocking framework to do this.

Keep it on hand to run your unit tests against, that is unless you use something like Rhino Mocks(my personal favorite mocking framework).

Answer 5

To debug the base class, create an instance of one of the derived classes and debug through that.

You might also consider creating another derived class which doesn't do anything except inherit from the base class so you can test it.

Answer 6

Firstly, it doesn't need to be abstract for your classes to inherit from it, and if it isn't abstract you can instantiate it. Otherwise just debug it form within a concrete implementation

Answer 7

You could create a derived version in your test fixture assembly (I'm assuming you are unit testing the base, hence the need to instantiate it individually) just for the purposes of testing the functionality of the base class. The derived version would provide any additional infrastructure needed to test the base. You may decide to create several derived versions to test different aspects of the abstract base.

Answer 8

You would debug it by using the derived classes that inherit from it. When debugging it you will need to keep in mind any changes that you make and review if the resulting behaviour is still shared by all derived classes.