[oo] How do I guarantee that a certain set of classes has a given static method?

[growse]

I can't seem to figure this one out.

I've got a bunch of classes (lets say, RedBox, BlueBox and GreenBox) which all implemtn IBox. This works perfectly. However, I now have a requirement that each box implements a particular static method, so I can get a non-instance-specific bit of data out. Lets call it GetVersion().

Whilst I can create a GetVersion method in IBox and ensure that each Box implements it as an instance method, that means that to call GetVersion, I need to instantiate an object of the class, and then call it. This seems a bit of a waste, given that what I want from the class is specific to the class, and not any particular instance of the class.

Is there a way of enforcing the existence of a static GetVersion() on everything that implements IBox? I thought about creating an abstract Box class and using inheritance, but you can't mark a static method as being virtual and force it to be overridden.

Any ideas?

 

[growse]

http://stackoverflow.com/questions/...c-class-to-implement-certain-static-functions - Answer your question?

Thanks, seems like I can't, without some distinct jiggery pokery.

Surely this just highlights that there is a design flaw. Why on Earth would you want *all* of your classes to implement a given static member, and then use the "[oo]" tag in the same sentence just to rub salt in the insult?

From what I've been reading around, this seems to be a useful thing that C# doesn't support. I don't want *all* of my classes to implement a given method, just a few that all implement a particular interface.

In my case, there's a particular bit of information about the class that I need to get out of the class, and I rely on calling a method to generate that info and return it. Another use case might be where I want to ensure that all classes that implement a given interface have a static factory method, so i know that I can always call Redbox.Factory().

OO is great. It's nowhere near perfect.

 

[growse]

Calling a Factory in that fashion is a complete fallacy. The whole point to using a Factory is to decouple your class/object dependency, yet you've gone right past that and hard-coded the class name in. Why?

This isn't OO. "Implementing" a static member is not OO. Hard coupling your classes is not OO.

Ok, so the factory was a bad example.

Are you saying it's *always* a bad design pattern to have a set of similar classes you want to be able to call the same static method on?

 

[growse]

I'm saying it is bad practice to try and decorate static members, yes. Don't use static, is frankly what I am saying.

What do you need them to be static for? Why aren't you passing objects around instead of classes?

It's basically a plugin-like system, the application looks in a directory for other dll's, iterates over each one, checks to see if they're valid and contain a Class that implements the plugin interface, and if they do, loads the assembly and chucks a note in a collection to keep track of what plugins have been loaded.

Currently, if I want to iterate through that list and get that class to do something, I can only really put that method in the interface and then make an instance of that class whenever I need that doing. All I'm really after is knowing if it's possible to have a static method that I can rely on existing for a given class.

Thinking about it, I could just do this by having a single abstract 'Plugin' class that implemented the static method, and have all the children override that if they need to.

 

[growse]

Could hack it with Reflection, but even that is smelly tbh.

As long as the class implements a "IPlugin" interface/extends an abstract "Plugin" class, I don't see the need for a static method.

Are your concerns about DI?

There's no issue at all in doing it as an interface method, but it seems a bit of a waste to make an instance just to get some information out of the class, especially given that that information is specific to the class itself, and not to any specific object.

My concern is that if I want a plugin class to look like a specific 'thing', I can only say what instances of that class look like, and not the class itself.