We Keep Coding

What is the reason behind C# allowing the overloading of interface properties? [duplicate]

So, what exactly is a good use case for implementing an interface explicitly?
Is it only so that people using the class don't have to look at all those methods/properties in intellisense?

If you implement two interfaces, both with the same method and different implementations, then you have to implement explicitly.
public interface IDoItFast
{
void Go();
}
public interface IDoItSlow
{
void Go();
}
public class JustDoIt : IDoItFast, IDoItSlow
{
void IDoItFast.Go()
{
}
void IDoItSlow.Go()
{
}
}

It's useful to hide the non-preferred member. For instance, if you implement both IComparable<T> and IComparable it is usually nicer to hide the IComparable overload to not give people the impression that you can compare objects of different types. Similarly, some interfaces are not CLS-compliant, like IConvertible, so if you don't explicitly implement the interface, end users of languages that require CLS compliance cannot use your object. (Which would be very disastrous if the BCL implementers did not hide the IConvertible members of the primitives :))
Another interesting note is that normally using such a construct means that struct that explicitly implement an interface can only invoke them by boxing to the interface type. You can get around this by using generic constraints::
void SomeMethod<T>(T obj) where T:IConvertible
Will not box an int when you pass one to it.

Some additional reasons to implement an interface explicitly:
backwards compatibility: In case the ICloneable interface changes, implementing method class members don't have to change their method signatures.
cleaner code: there will be a compiler error if the Clone method is removed from ICloneable, however if you implement the method implicitly you can end up with unused 'orphaned' public methods
strong typing:
To illustrate supercat's story with an example, this would be my preferred sample code, implementing ICloneable explicitly allows Clone() to be strongly typed when you call it directly as a MyObject instance member:
public class MyObject : ICloneable
{
public MyObject Clone()
{
// my cloning logic;
}
object ICloneable.Clone()
{
return this.Clone();
}
}

Another useful technique is to have a function's public implementation of a method return a value which is more specific than specified in an interface.
For example, an object can implement ICloneable, but still have its publicly-visible Clone method return its own type.
Likewise, an IAutomobileFactory might have a Manufacture method which returns an Automobile, but a FordExplorerFactory, which implements IAutomobileFactory, might have its Manufacture method return a FordExplorer (which derives from Automobile). Code which knows that it has a FordExplorerFactory could use FordExplorer-specific properties on an object returned by a FordExplorerFactory without having to typecast, while code which merely knew that it had some type of IAutomobileFactory would simply deal with its return as an Automobile.

It's also useful when you have two interfaces with the same member name and signature, but want to change the behavior of it depending how it's used. (I don't recommend writing code like this):
interface Cat
{
string Name {get;}
}
interface Dog
{
string Name{get;}
}
public class Animal : Cat, Dog
{
string Cat.Name
{
get
{
return "Cat";
}
}
string Dog.Name
{
get
{
return "Dog";
}
}
}
static void Main(string[] args)
{
Animal animal = new Animal();
Cat cat = animal; //Note the use of the same instance of Animal. All we are doing is picking which interface implementation we want to use.
Dog dog = animal;
Console.WriteLine(cat.Name); //Prints Cat
Console.WriteLine(dog.Name); //Prints Dog
}

It can keep the public interface cleaner to explicitly implement an interface, i.e. your File class might implement IDisposable explicitly and provide a public method Close() which might make more sense to a consumer than Dispose().
F# only offers explicit interface implementation so you always have to cast to the particular interface to access its functionality, which makes for a very explicit (no pun intended) use of the interface.

If you have an internal interface and you don't want to implement the members on your class publicly, you would implement them explicitly. Implicit implementations are required to be public.

Another reason for explicit implementation is for maintainability.
When a class gets "busy"--yes it happens, we don't all have the luxury of refactoring other team members' code--then having an explicit implementation makes it clear that a method is in there to satisfy an interface contract.
So it improves the code's "readability".

A different example is given by System.Collections.Immutable, in which the authors opted to use the technique to preserve a familiar API for collection types while scraping away the parts of the interface that carry no meaning for their new types.
Concretely, ImmutableList<T> implements IList<T> and thus ICollection<T> (in order to allow ImmutableList<T> to be used more easily with legacy code), yet void ICollection<T>.Add(T item) makes no sense for an ImmutableList<T>: since adding an element to an immutable list must not change the existing list, ImmutableList<T> also derives from IImmutableList<T> whose IImmutableList<T> Add(T item) can be used for immutable lists.
Thus in the case of Add, the implementations in ImmutableList<T> end up looking as follows:
public ImmutableList<T> Add(T item)
{
// Create a new list with the added item
}
IImmutableList<T> IImmutableList<T>.Add(T value) => this.Add(value);
void ICollection<T>.Add(T item) => throw new NotSupportedException();
int IList.Add(object value) => throw new NotSupportedException();

In case of explicitly defined interfaces, all methods are automatically private, you can't give access modifier public to them. Suppose:
interface Iphone{
void Money();
}
interface Ipen{
void Price();
}
class Demo : Iphone, Ipen{
void Iphone.Money(){ //it is private you can't give public
Console.WriteLine("You have no money");
}
void Ipen.Price(){ //it is private you can't give public
Console.WriteLine("You have to paid 3$");
}
}
// So you have to cast to call the method
class Program
{
static void Main(string[] args)
{
Demo d = new Demo();
Iphone i1 = (Iphone)d;
i1.Money();
((Ipen)i1).Price();
Console.ReadKey();
}
}
// You can't call methods by direct class object

This is how we can create Explicit Interface:
If we have 2 interface and both the interface have the same method and a single class inherit these 2 interfaces so when we call one interface method the compiler got confused which method to be called, so we can manage this problem using Explicit Interface.
Here is one example i have given below.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace oops3
{
interface I5
{
void getdata();
}
interface I6
{
void getdata();
}
class MyClass:I5,I6
{
void I5.getdata()
{
Console.WriteLine("I5 getdata called");
}
void I6.getdata()
{
Console.WriteLine("I6 getdata called");
}
static void Main(string[] args)
{
MyClass obj = new MyClass();
((I5)obj).getdata();
Console.ReadLine();
}
}
}

How to cast a generic to the interface it implements when the type parameters on both implement a common interface in C#

Consider the following code:
public class Thing : IThing { }
public interface IThing {}
public interface IContainer<out T> where T : IThing { }
// This works
// public class Container<T> : IContainer<T> where T : IThing { }
// This doesn't work
public class Container<T> : IContainer<IThing> where T : IThing {}
internal class Program
{
private static void Main(string[] args)
{
var concreteContainer = new Container<Thing>();
var abstractContainer = (IContainer<Thing>) concreteContainer;
}
}
On this line:
var abstractContainer = (IContainer<Thing>) concreteContainer;
You get the following runtime error:
InvalidCastException: Unable to cast object of type 'CastTest.Container`1[CastTest.Thing]' to type CastTest.IContainer`1[CastTest.Thing]'.
Also if you have Resharper, it complains with, Suspecious cast: there is no type in the solution which is inherited from both 'Container<Thing>' and 'IContainer<Thing>'.
Why does there need to be a type that inherits from both? Doesn't Container<T> implement IContainer<IThing>? Since Thing implements IThing, and T in Container<T> is guaranteed to implement IThing, it seems like I should be able to do this cast.

Doesn't Container<T> implement IContainer<IThing>?
It does.
Since Thing implements IThing, and T in Container<T> is guaranteed to implement IThing, it seems like I should be able to do this cast.
out works the other way around. out means that if the type implements IContainer<Thing>, it automatically implements IContainer<IThing> as well. Not vice versa.
It's called out because it can return something. You might have for instance
interface IThing<out T> {
T Prop { get; }
}
Now, IContainer<Apple> would automatically implement IContainer<Fruit>, and IContainer<Banana> would also automatically implement IContainer<Fruit>. That works, because something which returns an Apple can be interpreted as returning a Fruit. But if you only know it returns a Fruit, you don't know whether that Fruit is an Apple.
in works the way you ask. You might have for instance
interface IThing<in T> {
void Act(T t);
}
Now, IContainer<Apple> does not automatically implement IContainer<Fruit>. That's because something which requires an Apple won't be able to accept arbitrary Fruits. But something which only requires a Fruit does accept all Apples.

Implementing interfaces in C++

I usually program in C# but am trying to do a bit of C++ and am struggling somewhat trying to implement interfaces in C++.
In C# I'd do something like this:
class Base<T>
{
public void DoSomething(T value)
{
// Do something here
}
}
interface IDoubleDoSomething
{
void DoSomething(double value);
}
class Foo : Base<double>, IDoubleDoSomething
{
}
In C++ I've implemented it like this:
template <class T>
class Base
{
public:
virtual void DoSomething(T value)
{
// Do something here
}
};
class IDoubleDoSomething
{
public:
virtual void DoSomething(double value) = 0;
};
class Foo : public Base<double>, public IDoubleDoSomething
{
};
The problem is that I cannot instantiate Foo because it is abstract (doesn't implement DoSomething). I realise I can implement DoSomething and just call the method on Base but I was hoping there is a better way of doing this. I have other classes which inherit from base with different data types and I have other classes which inherit from IDoubleDoSomething which don't use Base.
Any help appreciated.

Consider the following c++ code
class Foo
{
public:
void DoSomething1(){}
};
template<typename t>
void MethodExpectsDosomething1( t f )
{
f.DoSomething1();
}
template<typename t>
void MethodExpectsDosomething2( t f )
{
f.DoSomething2();
}
int main()
{
Foo f;
MethodExpectsDosomething1<Foo>( f );
MethodExpectsDosomething2<Foo>( f );
return 0;
}
In C++ you can use Foo without it implementing a IDoSomething1 and IDoSomething2. The second method MethodExpectsDosomething2 will simply fail to compile as Foo doesn't have the DoSomething2 method.
In C# such construct is not possible and forces you to have IDoSomething1 and IDoSomething2 interface and specify that as a type constraint.
So maybe you need to look at your code and see if such interfaces are needed at all ?

The thing is, Base::DoSomething and IWhatever::DoSomething are two unrelated functions (even if there weren't any pure virtual functions in this, you wouldn't be able to call DoSomething on a Foo object, anyway). Base needs to inherit from IWhatever for this to work.
That said, ask yourself if you actually need this. Generic programming with templates (and concepts, which are sort of like interfaces — see Boost.ConceptCheck) is usually a better solution in C++ than runtime subtype polymorphism.

You could pass a second template parameter to Base, the interface that it is to implement:
template <typename T, class Interface>
class Base : public Interface { ... };
class Foo : public Base<double, IDoubleDoSomething> { ... };
For extra bonus points you could templatise IDoubleDoSomething (so it's eg IDoSomething<double>), or use a traits class to map the type T to the relevant interface.

In C++, pure virtual functions must always be overridden in a derived class; they can't inherit overrides from other base classes like that. If you need dynamic polymorphism, I don't think there's any sensible alternative to writing a function in Foo that calls the Base function. Note that the Base function doesn't need to be virtual.
Depending on how you're using these classes (in particular whether the real type of each instance of the interface is known at compile time), you may be able to use static polymorphism to inject your particular implementation class into its user as a template parameter; for example:
// No explicit interface specification with static polymorphism
class Foo : public Base<double>
{
// Inherits DoSomething(double)
};
// Template can used with any class that impelements a
// "DoSomething" function that can accept a double.
template <class DoubleDoSomething>
void DoSomethingWithDouble(DoubleDoSomething & interface, double value)
{
interface.DoSomething(value);
}
// This particular specialisation uses a "Foo" object.
Foo foo;
DoSomethingWithDouble(foo, 42);

As others have noted, the two functions in the base classes are unrelated (despite having the same name and argument types), as they have no common base class. If you want them to be related, you need to give them a common base class.
Also, in general, if you want multiple inheritance to work properly, you need to declare your non-private base classes as virtual. Otherwise, if you ever have common base classes (as you often need for this style of code), bad things will happen.
So given that, you can make your example work as follows:
template <class T>
class IDoSomething {
public:
virtual void DoSomething(T value) = 0;
};
template <class T>
class Base : public virtual IDoSomething<T>
{
public:
virtual void DoSomething(T value)
{
// Do something here
}
};
class IDoubleDoSomething : public virtual IDoSomething<double>
{
};
class Foo : public virtual Base<double>, public virtual IDoubleDoSomething
{
};

Provided everything else is in order, this should work.
class Foo : public Base<double>
{
};
In your original code Foo would have 2 void DoSomething(double value) methods (1 being abstract).
That would be an Base part and an IDoubleDoSomething part.
Foo::Base and Foo::IDoubleDoSomething.
You could try it by temporarily giving and implementation to IDoubleDoSomething.DoSomething().
But since Foo already "is a" Base" you have what you need without IDoubleDoSomething.

A generic method can use contravariant/covariant types?

I'm writting a generalized method to use it in a special task at a T4 template. The method should allow me to use specialized types from a general interface. I thought about the following signatures:
interface IGreatInterface {
Object aMethodAlpha<U>(U parameter) where U : IAnInterface;
Object aMethodBeta(IAnInterface parameter)
}
public class AnInterestingClass : IAnInterface{}
When I try to implement IGreatInterface the compiler flags an error for aMethodBeta() because I've made my T4 to write that method using a subtype of IAnInterface (i.e. I want to implement that method like this: Object aMethodBeta(AnInterestingClass parameter)).
Method aMethodAlpha<U>() can be used but is not as clean as I want because my T4 has to generate some extra code. I (perhaps wrongly)
propose that an implementation of that method, which has to be done by a T4, could be
Object aMethodAlpha<AnInterestingClass>(AnInterestingClass parameter).
I'm thinking that generic methods do not support contravariant types but I'm not sure; I suppose that It's the way the compiler prevents the coder to use a specific type having a method not defined in the general type...
Does a generic method have to use the exact type when being implemented?
Is there any trick to change this behavior?

This question is quite confusing. Let me see if I can clarify it.
When I try to implement IGreatInterface the compiler flags an error for aMethodBeta() because I've made that method using a subtype of IAnInterface I want to implement that method like this: Object aMethodBeta(AnInterestingClass parameter).
That's not legal. Simplifying somewhat:
class Food {}
class Fruit : Food {}
class Meat : Food {}
interface IEater
{
void Eat(Food food);
}
class Vegetarian : IEater
{
public void Eat(Fruit fruit);
}
Class Vegetarian does not fulfill the contract of IEater. You should be able to pass any Food to Eat, but a Vegetarian only accepts Fruit. C# does not support virtual method formal parameter covariance because that is not typesafe.
Now, you might then say, how about this:
interface IFruitEater
{
void Eat(Fruit fruit);
}
class Omnivore : IFruitEater
{
public void Eat(Food food);
}
Now we have got type safety; Omnivore can be used as an IFruitEater because an Omnivore can eat fruit, as well as any other food.
Unfortunately, C# does not support virtual method formal parameter type contravariance even though doing so is in theory typesafe. Few languages do support this.
Similarly, C# does not support virtual method return type variance either.
I'm not sure if that actually answered your question or not. Can you clarify the question?
UPDATE:
What about:
interface IEater
{
void Eat<T>(T t) where T : Food;
}
class Vegetarian : IEater
{
// I only want to eat fruit!
public void Eat<Fruit>(Fruit food) { }
}
Nope, that's not legal either. The contract of IEater is that you will provide a method Eat<T> that can take any T that is a Food. You cannot partially implement the contract, any more than you could do this:
interface IAdder
{
int Add(int x, int y);
}
class Adder : IAdder
{
// I only know how to add two!
public int Add(2, int y){ ... }
}
However, you can do this:
interface IEater<T> where T : Food
{
void Eat(T t);
}
class Vegetarian : IEater<Fruit>
{
public void Eat(Fruit fruit) { }
}
That is perfectly legal. However, you cannot do:
interface IEater<T> where T : Food
{
void Eat(T t);
}
class Omnivore : IEater<Fruit>
{
public void Eat(Food food) { }
}
Because again, C# does not support virtual method formal parameter contravariance or covariance.
Note that C# does support parametric polymorphism covariance when doing so is known to be typesafe. For example, this is legal:
IEnumerable<Fruit> fruit = whatever;
IEnumerable<Food> food = fruit;
A sequence of fruit may be used as a sequence of food. Or,
IComparable<Fruit> fruitComparer = whatever;
IComparable<Apples> appleComparer = fruitComparer;
If you have something that can compare any two fruits then it can compare any two apples.
However, this kind of covariance and contravariance is only legal when all of the following are true: (1) the variance is provably typesafe, (2) the author of the type added variance annotations indicating the desired co- and contra-variances, (3) the varying type arguments involved are all reference types, (4) the generic type is either a delegate or an interface.

If you want to inherit from a generic interface, see phoog's answer. If you are talking about trying to implement an interface co-variantly, that leads to my discussion below.
Assume:
internal interface IAnInterface { }
public class SomeSubClass : IAnInterface { }
public class AnotherSubClass : IAnInterface { }
public GreatClass : IGreatInterface { ... }
The problem with trying to implement the interface with a more derived (co-variant) argument is there's no guarante when this is called through an interface that an IAnInterface passed in will be a SomeSubClass instance. This is why it's not allowed directly.
IGreatInterface x = new GreatClass();
x.aMethodBeta(new AnotherSubClass());
IF You could do covariance, this would fail because you would be expecting a SomeSubClass but would get a AnotherSubClass.
What you could do is to do explicit interface implementation:
class GreatInterface : IGreatInterface
{
// explicitly implement aMethodBeta() when called from interface reference
object IGreatInterface.aMethodBeta(IAnInterface parameter)
{
// do whatever you'd do on IAnInterface itself...
var newParam = parameter as SomeSubClass;
if (newParam != null)
{
aMethodBeta(newParam);
}
// otherwise do some other action...
}
// This version is visible from the class reference itself and has the
// sub-class parameter
public object aMethodBeta(SomeSubClass parameter)
{
// do whatever
}
}
Thus, if you did this, your interface supports the generic, the class has a more specific method, but still supports the interface. The main difference is you'd need to handle the case where an unexpected implementation of IAnInterface is passed in.
UPDATE: it sounds like you want something like this:
public interface ISomeInterface
{
void SomeMethod<A>(A someArgument);
}
public class SomeClass : ISomeInterface
{
public void SomeMethod<TA>(TA someArgument) where TA : SomeClass
{
}
}
This is not allowed, when you implement a generic method from an interface, the constraints must match.

Maybe you're looking for this:
interface IGreatInterface<in U> where U : IAnInterface
{
Object aMethodAlpha(U parameter);
}
class SomeClass : IAnInterface { /*...*/ }
class GreatClass : IGreatInterface<SomeClass>
{
public Object aMethodAlpha(SomeClass parameter) {}
}
EDIT:
Yes, you are right: if you define a generic method in an interface, you can't implement that method with a concrete method using a compatible type.
How about using a delegate (since delegates support co- and contravariance):
[example deleted because I got the variance backwards -- it doesn't work.]

Cast to multiple interfaces [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Casting an object to two interfaces at the same time, to call a generic method
I'm fairly sure you can't do this so I'm wondering if there's a workaround, but I need/want to cast an object to represent multiple interfaces for use with generic constraints. For example:
public void Foo<T>(T t) where T : IInterfaceA, IInterfaceB
{
}
If I have an object I want to say something like var t = (IInterfaceA | IInterfaceB)someObj; so I can pass t into this method.
Is there a nifty way of doing this? I'm using C# 3.5 so no dynamic available, but if it's possible with dynamic please post it anyway.

EDIT
Despite the answer below, I would say the better solution is the one that most other answers point to. (This assumes that you can redefine the multiple classes that implement both interfaces.)
Create an interface that inherits from both InterfaceA and InterfaceB, then, for all classes that implement interfaces A and B, replace those interfaces with the new one. Before:
class SomeClass : IInterfaceA, IInterfaceB { }
class AnotherClass : IInterfaceA, IInterfaceB { }
class AdditionalClass : IInterfaceA, IInterfaceB { }
After:
interface IInterfaceC : IInterfaceA, IInterfaceB { }
class SomeClass : IInterfaceC { }
class AnotherClass : IInterfaceC { }
class AdditionalClass : IInterfaceC { }
The implementation of Foo is then fairly trivial. And, again, since you don't know at compile time what type you have on hand, you may be able just to declare it as
public void Foo(IInterfaceC someObj) { }
END EDIT
You can do it using reflection, though some will say that this isn't particularly "nifty":
public class FooClass
{
public void Foo<T> (T t) where T : IInterfaceA, IInterfaceB
{
//... do your thing here
}
private static void Example(object someObj)
{
var type = someObj.GetType();
if(typeof(IInterfaceA).IsAssignableFrom(type) && typeof(IInterfaceB).IsAssignableFrom(type))
{
var genericMethod = typeof(FooClass).GetMethod("Foo");
var constructedMethod = genericMethod.MakeGenericMethod(type);
var instance = new FooClass();
var result = constructedMethod.Invoke(instance, new [] { someObj });
Assert.IsNull(result);
}
}
}
you could also do this, which could allow you to make Foo non-generic. It's also fairly ugly, so I would hide this ugliness by making it private:
private void PrivateFoo(IInterfaceA objA, IInterfaceB objB)
{
if (!ReferenceEquals(objA, objB))
throw new ArgumentException("objA and objB must refer to the same object");
//... do your thing here
}
public void Foo(object someObj)
{
PrivateFoo((IInterfaceA)someObj, (IInterfaceB)someObj);
}

public void Foo<T>(T t) where T : IInterfaceA, IInterfaceB{}
{
// T already implements IInterfaceA and IInterfaceB, just call the methods.
t.MethodFromA();
t.MethodFromB();
}
T t = (T)someObj;
This will cast the object to T, not the two interfaces... so it's up to you to make sure that'll work.
IInterfaceA tA = (IInterfaceA)someObj;
IInterfaceB tB = (IInterfaceB)someObj;
Two references to the one instance.

No, there is no way.
The only thing that comes close is to create another interface the inherits those two interfaces. But then all your classes need to implement that third interface instead of the two others, so in most circumstances, this is not practical.
Just cast it to that interface you need at that moment.
UPDATE:
The only way I can see is to create a container class that implements those interfaces:
class Container : IInterfaceA, IInterfaceB
{
private object _obj;
public Container(object obj)
{
// Check that the object really implements those two interfaces.
_obj = obj;
}
void IInterfaceA.Method1()
{
((IInterfaceA)_obj).Method1();
}
// And so on for all methods of the interfaces.
}

One possible way to do this is have inheritance of interfaces. Move the common functionality, to the parent interface, which should be used in above scenarios.

You may be able to restructure your inheritance to achieve your goal.
public class ArrayList : IList, ICollection, IEnumerable, ICloneable
public interface IList : ICollection, IEnumerable
Note that ArrayList inerits from IList, which inherits from two interfaces already included in Arraylist.