So I have a class A. It defines a lot of the behaviour (methods), but also leaves a lot to the subclasses to implement. This class is never going to have an instance. This is just going to define the behaviour that is common to all subclasses. The subclasses (A1, A2, A3, etc.) that are going to extend A are all going to be singletons. I don't want these subclasses to have multiple instances.
So the obvious way to do this would be create an abstract class A and then static classes A1, A2, A3 that extend A.
But apparently, this isn't allowed in C#. I'm assuming there is a good reason for this. People at Microsoft probably know a lot more about objected-oriented software design than I do. But I just need some help in figuring out why this design is "poor" and what would be an alternate better design.
I'm writing a RESTful API using WCF. There is a bunch of database tables that this service is going to perform CRUD operations on. There is a lot of code that is going to be common to all tables and a lot of code that is going to be specific to each table. Also, only one operation can be performed on the table at any given time.
So I thought I could have an abstract class TableHandler
. And then multiple extensions of it such as TableAHandler
, TableBHandler
etc. Since I only want one instance of these subclasses, I wanted to make them static.