Question

First off, I understand the reasons why an interface or abstract class (in the .NET/C# terminology) cannot have abstract static methods. My question is then more focused on the best design solution.

What I want is a set of ‘helper’ classes that all have their own static methods such that if I get objects A, B, and C from a third party vendor, I can have helper classes with methods such as

 AHelper.RetrieveByID(string id); AHelper.RetrieveByName(string name); AHelper.DumpToDatabase(); 

Since my AHelper, BHelper, and CHelper classes will all basically have the same methods, it seems to makes sense to move these methods to an interface that these classes then derive from. However, wanting these methods to be static precludes me from having a generic interface or abstract class for all of them to derive from.

I could always make these methods non-static and then instantiate the objects first such as

 AHelper a = new AHelper(); a.DumpToDatabase(); 

However, this code doesn’t seem as intuitive to me. What are your suggestions? Should I abandon using an interface or abstract class altogether (the situation I’m in now) or can this possibly be refactored to accomplish the design I’m looking for?

Answer 1

Looking at your response I am thinking along the following lines:

• You could just have a static method that takes a type parameter and performs the expected logic based on the type.
• You could create a virtual method in your abstract base, where you specify the SQL in the concrete class. So that contains all the common code that is required by both (e.g. exectuting the command and returning the object) while encapsulating the ‘specialist’ bits (e.g. the SQL) in the sub classes.

I prefer the second option, although its of course down to you. If you need me to go into further detail, please let me know and I will be happy to edit/update 🙂