Reputation: 30837
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 ?
Upvotes: 0
Views: 571
Reputation: 116827
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:
interfaces
might be a good choice)Upvotes: 1
Reputation: 494
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...
Upvotes: 1
Reputation: 19842
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.
Upvotes: 1
Reputation: 64467
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.
Upvotes: 0
Reputation: 19175
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.
Upvotes: 0
Reputation: 20451
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
Upvotes: 0
Reputation: 2462
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.
Upvotes: 0
Reputation: 6683
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).
Upvotes: 0