We Keep Coding

C# method implementation with dot notation

Reading an article I came across the following C# syntax in method name.
private class sortYearAscendingHelper : IComparer
{
int IComparer.Compare(object a, object b)
{
...
}
}
I understand Compare method is method of IComparer interface, but coming from C++ I am not certain what this syntax means. If Compare is part of interface, I would expect to mention that only like int Compare(...). Why we have to specify class?

That is an explicit interface implementation You use it when you derive from multiple interfaces that contain similar (same signature) functions but need different implementations for each interface.
More information can be found on MSDN.
(Sample from linked page):
If the two interface members do not perform the same function,
however, this can lead to an incorrect implementation of one or both
of the interfaces. It is possible to implement an interface member
explicitly—creating a class member that is only called through the
interface, and is specific to that interface. This is accomplished by
naming the class member with the name of the interface and a period.
For example:
public class SampleClass : IControl, ISurface
{
void IControl.Paint()
{
System.Console.WriteLine("IControl.Paint");
}
void ISurface.Paint()
{
System.Console.WriteLine("ISurface.Paint");
}
}
The class member IControl.Paint is only available through the IControl
interface, and ISurface.Paint is only available through ISurface. Both
method implementations are separate, and neither is available directly
on the class.

How come an interface instance has GetType, GetHashCode, Equals and ToString methods?

Consider the following example.
public interface IAnimal
{
void MakeSound();
}
public class Dog: IAnimal
{
public void MakeSound() { Console.WriteLine("Bow-Bow-Bow"); }
public static void Main()
{
IAnimal a = new Dog();
Console.WriteLine(a.MakeSound());
Console.WriteLine(a.ToString());
}
}
How come the interface instance can access ToString method that was from System.Object? My understanding is, with interface, one can access only the methods the interface holds.

Your class implicitly derived from System.Object :
Languages typically do not require a class to declare inheritance from Object because the inheritance is implicit. [MSDN]
UPDATE :
Just found this, possible duplicate? :
Do interfaces derive from System.Object? C# spec says yes, Eric says no, reality says no

Because everything is an object. It's a cheeseball answer, but that's how .NET works. :)

My understanding is, with interface, one can access only the methods
the interface holds.
Actually, with an interface you can access the methods the interface holds and all members of System.Object (as you have discovered). This doesn't mean that interfaces themselves derives from System.Object, it just means that the compiler has a "special case" when checking for members on variables declared as interfaces.
The compiler can do this because interfaces are implemented by objects and all objects derive from System.Object.
So when a is declared as IAnimal it really means that the variable a contains an object which implement the interface IAnimal. This object is guaranteed to support all members in IAnimal and all members System.Object.

Inherited Interfaces In C#

In c sharp abstract methods must be implemented by child class. So my question is when an interface inherits another interface why doesn't it implement all of base interface members.
public interface IShape
{
void Points();
}
public interface ICircle: IShape
{
void IsDrawAble();
}
When i run this program in Visual Studio 2010 and no error came up. By definition ICircle must implement Points function.
Thanks

Interfaces don't implement anything.
An interface simply contains a list of members that concrete classes need to implement.
There would be no point in re-declaring members that were already required by a base interface.
Similarly, an abstract class that inherits another abstract class (or interface) does not need to implement any of its methods.

When you implement ICircle you'll need to implement Points() as well. The following code does not compile:
class MyClass : ICircle
{
void IsDrawAble() { }
}
So what you stated should be : "By definition all implementations of ICircle must implement the IShape members as well"

You answered the question yourself. Because it's an interface. Interfaces are not classes, therefore they don't have to (in fact cannot) implement other interfaces they inherit.

When you create this kind of hierarchy between interfaces, you are defining who implement the Circle interface will also implement IShape. So, for sample:
public class Test : ICircle
{
public void Points()
{
// some code
}
public void IsDrawAble()
{
// some code
}
}
Using it:
ICircle obj = new Test();
obj.Points();
obj.IsDrawAble();
or
IShape obj = new Test();
obj.Points();

An interface represents a contract. They contain only the signatures of methods, properties, events or indexers. An interface doesn't implement at all. A class/struct that implements an interface must implement the members of the interface that are specified in the interface definition.
The hierarchy you have created simply means that whatever implements the ICircle interface also implements the IShape interface.

Predefined Interface exposes some method,we are using that method but interface doent have definition part ,then how its working in c#?

Interface exposes some method,we are using that method in class but interface doent have definition part ,then how its working in c#.
For Example
class ProductNameComparer : IComparer
{
public int Compare(object x, object y)
{
Product first = (Product)x;
Product second = (Product)y;
return first.Name.CompareTo(second.Name);
}
}
Here IComparer exposes CompareTo() method, but IComparer doesn't have CompareTo() method definition part, then how its working?

Interface are simply contract which only declares method rather than having implementation part....Class which implements that particular Interface should have implemenation detail.
For instance, You have IAnimal interface and Dog is a class which implements IAnimal interface,
public interface IAnimal
{
void Walk(); // Just declares the method, not implemenation
}
//Class implementing the interface
//must define the method specified in the interface
class Dog : IAnimal
{
public void Walk()
{
Console.WriteLine("Dog can walk");
}
}
In your example, you misunderstood the IComparer interface.
IComparer defines an interface with a Compare() method
whereas
CompareTo() is declared by IComparable interface.
In above code, you have implemented IComparer interface so, you are defining Compare() method details in your ProductNameComparer class.

An interface doesn't have any implementation, it's only a contract for how something should work.
You can't create an instance of an interface, you can only create instances of actual classes (or structs) that implement the interface. If you get a reference to an interface, it points to an actual object that implements the interface.
Any class that implements the interface has to implement all members of the interface, so if you have an actual object that fits the interface, you know that the method is implemented.
You can use an interface without any knowledge of any class that implements it, so you can write code that uses an interface even before there is any actual implementation of the interface.

Here IComparer exposes CompareTo() method, but IComparer doesn't have CompareTo() method definition part, then how its working?
If this is your question that I think you are very much misunderstanding what is going and what "exposed" means.
Using your example:
class ProductNameComparer : IComparer
{
public int Compare(object x, object y)
{
Product first = (Product)x;
Product second = (Product)y;
return first.Name.CompareTo(second.Name);
}
}
Your ProductNameComparer class is implementing IComparer. The requirement classes implementing IComparer is they contain a method with the signature Compare(object x, object y). This is the only thing that your ProductNameComparer is exposing. That is nothing else.
Now you are using CompareTo() within the method, but you are not exposing it publicly. It is difficult to explain in more detail without knowing the definition of Product.Name, but let's assume it is a string.
System.String implements IComparable (among other interfaces), so string has a CompareTo() method. You are simply calling String.CompareTo() in your method, but nothing is exposed.

Interfaces define the contract between types, they don't define the implementation, that's up to the classes implementing the interface.
Consider:
interface IWorkable
{
void DoWork();
}
Then the implementation:
public class GoodWork : IWorkable
{
public void DoWork()
{
//add the implementation here
}
}

You should read a good c# tutorial before beginning to program..
http://www.codeproject.com/Articles/18743/Interfaces-in-C-For-Beginners

CompareTo method is not from IComparer but it is the method of your property first.Name which I suppose is a string.

Is this a good way to expose generic base class methods through an interface?

I am trying to provide an interface to an abstract generic base class. I want to have a method exposed on the interface that consumes the generic type, but whose implementation is ultimately handled by the classes that inherit from my abstract generic base.
However I don't want the subclasses to have to downcast to work with the generic type (as they already know what the type should be).
Here is a simple version of the only way I can see to get it to work at the moment.
public interface IFoo
{
void Process(Bar_base bar);
}
public abstract class FooBase<T> : IFoo
where T : Bar_base
{
abstract void Process(T bar);
// Explicit IFoo Implementation
void IFoo.Process(Bar_base bar)
{
if (bar == null) throw new ArgumentNullException();
// Downcast here in base class (less for subclasses to worry about)
T downcasted_bar = bar as T;
if (downcasted_bar == null)
{
throw new InvalidOperationException(
string.Format("Expected type '{0}', not type '{1}'",
T.ToString(), bar.GetType().ToString());
}
//Process downcasted object.
Process(downcasted_bar);
}
}
Then subclasses of FooBase would look like this...
public class Foo_impl1 : FooBase<Bar_impl1>
{
void override Process(Bar_impl1 bar)
{
//No need to downcast here!
}
}
Obviously this won't provide me compile time Type Checking, but I think it will get the job done...
Questions:
1. Will this function as I think it will?
2. Is this the best way to do this?
3. What are the issues with doing it this way?
4. Can you suggest a different approach?
Thanks!
Edit: In Response to many answers, It is a requirement that IFoo is not Generic. I need to be able to manipulate a collection of IFoo objects regardless of the generic Types they use.
Edit: In an effort to clarify the reasoning for this...
Bar_base contains a reference to type IFoo. And must call the process method to validate the data it contains. Think of IFoo as an object that contains validation logic for the Bar_base derived objects. When the validity of Bar_base object is questioned, it calls Process on its IFoo reference to validate itself.
The reason IFoo can't be generic is that I need to be able to reference a collection of IFoo independent of the Bar_base classes.
I am going to try the approach of having two interfaces a Generic one that contains the Process method, and non-generic one that doesn't.

In the case where IFoo cannot be generic, it's very typical in a case like this to have two interfaces, IFoo<T> and IFoo, where IFoo uses the most base class supported. Think IEnumerable<T> and IEnumerable. The non-generic version is usually hidden as an interface overload, so it only comes into play when accessing the class via the non-generic interface.

Given your constraint that T is of type Bar_base, and (in your example) only using T for Process(T bar), I'm not sure why you're using generics at all. If
abstract Process(Bar_base bar)
is all you need, then that should be sufficient for class overriding with
void override Process(Bar_impl1 bar)
and your abstract class Bar_base is a sufficient type constraint.
Unless I'm missing something....
Another useful trick is to provide both generic and non-generic interface definitions, where the non-generic provides non-generic access methods and properties, and the generic interface provides only the additional methods and/or properties that requires a generic type. Clients can specify either interface, depending on whether they're in a position to share the generic type.
interface IFoo
{
...
}
interface IFoo<T> : IFoo where T : Bar_base
{
...
}
But I'm not sure that this would satisfy your needs in this case.

You could just make IFoo generic:
public interface IFoo<T> where T : Bar_base
{
void Process(T bar);
}

Any reason you don't just use a generic interface:-
public interface IFoo<T>
where T:Bar_base
{
void Process(T bar);
}