Static method in Abstract class

Hello,
Firstly, I understand the reasons why an interface or abstract class (in the NET / C # / java terminology) can not have abstract static methods. My question is more focused on the best design solution. What I want is a set of helper classes that all have their own methods such as static, if I get the objects A, B and C from a third party vendor, I can have classes assistance with methods such as

Code:

---

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

---

Since my AHelper, BHelper, and classes will CHelper all basically the same methods, it seems logical to move these methods to an interface that these classes can be derived. However, wishing that these methods are static does not allow me to have a generic interface or an abstract class for all of them to draw conclusions. I could always do with these non-static methods, and then instantiate objects such as the first

Code:

---

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

---

However, this code does not seem as intuitive for me. What are your suggestions? Should I give up using an interface or abstract class altogether (the situation I'm in the business) or could it possibly be redesigned to accomplish the purpose that I seek?

If I were you I would try to avoid static. IMHO I always ended up a kind of synchronization problems on the road with the static. Having said that you have a classic example of generic programming using jigs. I will adopt the solution based on models presented in one of the java modules.

In you case the solution will be this code

Code:

---

public static T RetrieveByID <T> (string iden)
 (Var flnm = getFieldNamesBasedOnType (typeof (T));
  qyres webservice.query qy = ("SELECT" + flnm + "FROM"
                                      Tyepof + (T). Name
                                    + "WHERE iden = '" + iden + "'");
  return (T) qy.records [0];
 )

---

Given your response I think as follows:

- You could just have a static method that takes a type parameter and performs the usual logic based on gender.

- You can create a virtual method in your abstract base, where you specify the SQL in the concrete class. While containing all the common code that is required by both (eg the execution of the command and return the property) while encapsulating the specialist bits (eg SQL) in subclasses.

I prefer the second option, although its course down to you. If you need me to go into details, please let me know and I'll be happy to edit / update.

You can not overload methods by varying only the type of return. You can use different names:

Code:

---

static Aobj GetAObject (string iden);
static Bobj GetBObject (string iden);

---

Or you can create a class with casting operators:

Code:

---

AorBobj class
 (String iden;
  AorBobj (string iden) (this.iden = iden;)
  static public AorBobj RetrieveByID (string iden)
    (Return new AorBobj (iden);
    )
  public static explicit operator Aobj (AorBobj ab) 
    AObjectQuery (return (ab.iden);
    )
  public static explicit operator Bobj (AorBobj ab)
    BObjectQuery (return (ab.iden);
    ) 
 )

---

Then you can call it like this:

Code:

---

var a = (Aobj) AorBobj.RetrieveByID (8);
 var b = (Bobj) AorBobj.RetrieveByID (8);

---

How are Objects and AHelper related? Is AHelper.RetrieveByID (), the same logic as BHelper.RetrieveByID (). If yes, why not approach a utility class (class with public static methods only and no state) static [return type] Helper.RetrieveByID (ObjectX x).

Personally, I might be wondering why each type of need a static method before even thinking again
Why not create a utlity class with static methods they need to share? (Eg ClassHelper.RetrieveByID (string id) or ClassHelper <ClassA>. RetrieveByID (string id)
In my experience with these kinds of "roadblocks" the problem is not the limits of language, but the limits of my design.