tags:

views:

101

answers:

5

Hi,

I have a set of objects that I want to conform to an interface, say ISpecialObject. However a part of my implementation I want to encapsulate the instantiation trigger of these specialobjects within the implementation of each ISpecialObject.

So say for instance I have as list of class types that implement ISpecialObject, I then want to go through each one and call a static method like CanCreate(some data) which tells me whether or not to create an instance of one of these.

However, .net doesn't seem to let me specify this static CanCreate as part of the ISpecialObject interface.

Can anyone suggest a way to get around this, or alternatively a better approach to solving the problem of encapsulation of the instantiation of these objects? I may just be thinking about this all wrong.

Thanks.

Edit: I may have phrased some parts of this poorly. I don't want to provide the implementation in the interface, but rather specify that there will be one, and that it will be static. Essentially I want the objects to be self defining by allowing a higher level object to query when to create them at runtime.

+1  A: 

I dont see the issue. The typename is just a prefix when dealing with static methods. It will make no difference what so ever if the static method lives somewhere else.

That said, look at extension methods, which may do want you really want it to :)

Edit: Another option might be using attributes.

leppie
+3  A: 

From what I understand, your main issue is the instantiation of a set of objects that conform to the same interface. If that is so, you may want to look at the Factory Design Pattern which is the standard way to encapsulate such logic.

SirDemon
+1  A: 

.NET does not allow static method declarations on interfaces. They don't really make sense since interfaces are all about the contract and avoid implementation entirely. Static methods are specifically about implementation. Additionally, interface methods are virtual function calls depending on the type of the instance, whereas static methods are independent of an instance or even a class (they could be put on any concrete type).

If you have many implementations of ISpecialObject, you could use a factory pattern. In order to do this, you would define define an interface called ISpecialObjectFactory alongside ISpecialObject:

class ISpecialObjectFactory
{
    ISpecialObject CreateInstance(...);
    bool CanCreate(...);
}

Each class that implements ISpecialObject should have a corresponding ISpecialObjectFactory (e.g. UserObject would have also have a UserObjectFactory). This would require a bit more code, but it's a common pattern and I believe it solves your problem.

Chris Schmich
I hate this factory pattern, I like attributes much better.
leppie
I'm not a huge fan of factories, but wouldn't attributes be determined statically? What if `CanCreate` depends on runtime factors? Also, there's reflection involved, though you could cut it down to a one-time cost. I'd like to see more of what you mean.
Chris Schmich
@Chris Schmich: Look at any .NET IoC library. For custom behavior you could always call a (cough) factory. :)
leppie
You guys should check out Extension methods that extend an interface. They are a simpler approach to solving the problem in that they do provide an implementation for anyone who implements the interface.
Dave White
@leppie: ah, I see what you mean, though not all IoC libraries use attributes for wiring.
Chris Schmich
@Dave, @leppie: I think I might be mistaken in my understanding of the question. I was thinking that he wanted `CanCreate` to be polymorphic based on the type implementing `ISpecialObject`. In that case, factory/DI seems like the way to go. If he just wants one static method on the interface, then I agree, extension methods would be great.
Chris Schmich
I think this factory approach is the way to go for me, since I also realised that I may need to keep more state to decide whether CanCreate returns true or not. It's seems a little bit cumbersome this way, but I suppose that a factory for each ISpecialObject that determines when to create it is the neatest solution that actually works :)Thanks guys.
Bogdan Kiselitsa
+1  A: 

We just discussed something very similiar to this on another thread. Extension methods are definitely a way to solve this problem. They can provide an implementation for an interface, and the methods can be treated as static or used as a method on an instance of an object which is being extended.

It is not exactly a duplicate in the way that you've phrased the question, but it is duplicate in nature so check out the link below.

StackOverflow - subclass-needs-to-implement-interface-property-as-static

Dave White
Not quite. Extension methods still need an instance of the object. The question is asking about a static method.
Cameron MacFarland
A: 

Maybe you can use an abstract class as super class for your purpose. So the static methods go in the abstract class and all derived classes have that as well. However, I agree to the the posts above that may be using the factory pattern is a better approach here.

Sebastian