public abstract static ...

[Guest]

Hi,
I was just wondering, why is not possible to make a member of a class BOTH
abstract and static? MSDN says just that's in an error, not why this is so.
In a nutshell, I need this:
I have an abstract base class called EntityBase that all my other business
objects are derived from. I want to be able to load and save them in a
generic manner. I use a static method called EntityBase.GetByID(int id) and a
member method called EntityBase.Save(). I want to be able to force every
derived class to implement both of these methods, with this limitation I
can't though. Is there any workaround? Is there any reason for this
limitation in the first place?
Thanks!

 

[Joanna Carter [TeamB]]

"pali" <[email protected]> a écrit dans le message de (e-mail address removed)...

| I was just wondering, why is not possible to make a member of a class BOTH
| abstract and static? MSDN says just that's in an error, not why this is
so.
| In a nutshell, I need this:
| I have an abstract base class called EntityBase that all my other business
| objects are derived from. I want to be able to load and save them in a
| generic manner. I use a static method called EntityBase.GetByID(int id)
and a
| member method called EntityBase.Save(). I want to be able to force every
| derived class to implement both of these methods, with this limitation I
| can't though. Is there any workaround? Is there any reason for this
| limitation in the first place?

Neither constructors or static members are allowed to be virtual in C#; you
can only declare virtual (and abstract) instance methods. That is just one
of the few limitations of the language.

Are you sure you want your method to be accessible without having to
instantiate the class it is included in ?

Joanna

 

[Guest]

Yes, i know this is the limitation, I'm asking why? Is that a by-design choice?

I don't think it's meaningful to instantiate an instance of an object only
to be able to read/delete it from the store.
My typical class would look like this:
public class Customer : EntityBase
{
public static Customer GetByID(int id) {}
public void Save() {}
public static void Delete(int id) {}
}
In this case i don't see a reason to instantiate an object if I want to get
it from the database by id anyway. Same for the delete, I don't want to have
to get an entity from the database just to be able to delete it.
I want to put the signatures of those methods in the parent abstract class,
so I can get/save/delete them in a generic way...

 

[Joanna Carter [TeamB]]

"pali" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Yes, i know this is the limitation, I'm asking why? Is that a by-design
choice?

I guess so, Delphi has virtual static methods.

| I don't think it's meaningful to instantiate an instance of an object only
| to be able to read/delete it from the store.
| My typical class would look like this:
| public class Customer : EntityBase
| {
| public static Customer GetByID(int id) {}
| public void Save() {}
| public static void Delete(int id) {}
| }
| In this case i don't see a reason to instantiate an object if I want to
get
| it from the database by id anyway. Same for the delete, I don't want to
have
| to get an entity from the database just to be able to delete it.
| I want to put the signatures of those methods in the parent abstract
class,
| so I can get/save/delete them in a generic way...

Then how about factoring out the retrieval behaviour, which I would say
doesn't belong in the Customer class and use an Object Persistence Framework
instead ?

If you are using .NET 2.0, you can have methods on it like :

public class ObjectStore
{
public objectT RetrieveObject<objectT>(int Id)
{
...
}

...
}

Although I would also argue that most times you could retrieve a browsing
list for a criteria and then choose one object. That way you don't need to
know the ID outside of the OPF.

Joanna

 

[Guest]

Thanks,
i will try this template approach, looks nice

I've tried NHibernate and Gentle.NET as OPFs so far, both of them have quite
some limitations though, so I'll rather stick with my own "framework" and
code-generation templates...

Thanks!

 

[Nick Hounsome]

Yes, i know this is the limitation, I'm asking why? Is that a by-design
choice?

I don't think it's meaningful to instantiate an instance of an object only
to be able to read/delete it from the store.
My typical class would look like this:
public class Customer : EntityBase
{
public static Customer GetByID(int id) {}
public void Save() {}
public static void Delete(int id) {}
}
In this case i don't see a reason to instantiate an object if I want to
get
it from the database by id anyway. Same for the delete, I don't want to
have
to get an entity from the database just to be able to delete it.
I want to put the signatures of those methods in the parent abstract
class,
so I can get/save/delete them in a generic way...

How do you think that you would call an abstract static method?

EntityBase.Delete(32); // how can it know that you mean Customer?

Customer.Delete(32); // why would it need to be abstract in EntityBase?

If you mean that you should be able to call base static methods through
derived scope as you can in C++ then I agree with you but that doesn't seem
to be what you are asking.