tags:

views:

98

answers:

2

I have a class that have a different Add method than the other classes and therefor cant implement the same interface... Should I split the current interface so it can use it too or should I just create another interface for it?

UPDATE:

public interface IProductRepository<T, T2>
    where T : class
    where T2 : class
{
    void Add(T model, int categoryId);
    void Edit(T model, int id);
    void Delete(int id);

    T2 Get(int id);
}

As you see then the interface above have an Add method which requires a categoryId.

My Category class is the same as above but without the categoryId parameter in the Add method. Should I just create a new interface for the Category class?

+1  A: 

Think about what is for it.

Maybe your other class don't seems to be like to functionality of this interface rather than doing same action (adding). Then you can create other interface for this new (new other) type of classes or leave this class alone without abstract interface.

Maybe you want do some refactoring on other class to get definition of Add() smillar in interface.

If you can't refactor other class and this class seems to have this interface. Then you create other interface or in old interface new Function like Add_Extended() for adding functionality with other arguemnt list.

Svisstack
This answer confuses me more than the question.
kirk.burleson
I basically understand what they are saying. Essentially, *"Try to design your object model so this doesn't come up."*. They are Polish so, English is most likely a second language.
ChaosPandion
@ChaosPandion: thanks for support;-)
Svisstack
+4  A: 

C# allows you to explicitly implement an interface method:

public class A : IFoo, IBar{
    void IFoo.DoSomething() {
        //DoSomething();
    }
    int IBar.DoSomething() {
        return -1;
    }
}

This should allow you to implement any interface, even if it conflicts with method signatures that you already have defined. Which method gets called will depend on which Type it is being called on. For example:

((IFoo) new A()).DoSomething(); // ... may do something different than ...
((IBar) new A()).DoSomething(); // ... would do.
StriplingWarrior
You really should cast if you are expecting an object to be of a certain type. A `NullReferenceException` would not be very helpful when trying to debug.
ChaosPandion
I agree with chaos also it can also be written "IFoo foo = new A(); foo.DoSomething();"
Bear Monkey
I wish people wouldn't think of the 'as' operator as a nicer looking alternative to (cast). They are not the same!
Bear Monkey
[Fixed it :-p](http://meta.stackoverflow.com/questions/700/)
Timwi
@Timwi: mjf's suggestion is a cleaner way to do this, even if it requires a couple more characters. Using the cast notation for upcasts subverts useful compiler errors.
Ben Voigt
+1 But I think it will be better if you add a `default DoSomething method` in class A besides the explicitly implements of `IFoo.DoSomething` and `IBar.DoSomething`.
Danny Chen
@danny. You should only do that if IFoo.DoSomething and IBar.DoSomething are functionally identical. If they are not then its best to leave them explicitly defined.
Bear Monkey
Sorry about using the 'as' keyword. I practically never use it in my own code, but I was in a hurry and I figured it wasn't really crucial to the point of the question. Same with adding a non-explicit DoSomething method. He needed to know that explicit interface functions can exist. Beyond that, he can decide when and how to user them.
StriplingWarrior