I got the following code where i would like to know the relationship between those class and interface.
Multiple inheritance wont work with C# but can we implement using interface?
Please tell me whether the following code will complie or not? why it is so ?
I am very confused?
Pleasehelp me out........
public interface MyInterface
{
void Method();
}
public class Base
{
public void Method() { }
}
public class Derived : Base, MyInterface { }
Please tell me whether the following code will complie or not?
Yes, it will - but you could have found that out for yourself just by trying it.
Why it is so?
Quite simply, Derived implements the contract required by MyInterface. It happens to do that via Base which is unaware of the interface, but it still has all the relevant members.
There's a danger here, though - in reality, interfaces are about more than just having appropriate members available for callers; they're about the semantics of those members. A class hierarchy like this only works when the semantics of Base.Method() exactly match the requirements of MyInterface.Method() by coincidence (as opposed to by explicit, declared design). Even if it's valid to start with, the maintainer of Base may decide to make a change to the behaviour of Method which is valid according to what Base.Method has guaranteed, but isn't valid according to what the interface guarantees.
EDIT: In terms of the language specification, this is in section 13.4.4 of the C# 4 spec:
A class or struct must provide implementations of all members of the interfaces that are listed in the base class list of the class or struct. The process of locating implementations of interface members in an implementing class or struct is known as interface mapping.
Interface mapping for a class or struct C locates an implementation for each member of each interface specified in the base class list of C. The implementation of a particular interface member I.M, where I is the interface in which the member M is declared, is determined by examining each class or struct S, starting with C and repeating for each successive base class of C, until a match is located.
[...]
A compile-time error occurs if implementations cannot be located for all members of all interfaces specified in the base class list of C.
Related
We usually implement interfaces explicitly when it’s not right to access interface member directly from implementer class. Weather it has to be internal or it causes conflicts with API design or when it increases the chance of misusing methods.
Implementing members individually for multiple interfaces with different logic is absolutely discouraged in my mind so that’s not case here
Compiler does not allow making such implementation as virtual because it doesn't make sense and I think it’s right. Usually explicit implementation is very sensitive and that’s why you try to hide it.
However I found following way of over-riding explicit implementation (it’s not exactly override but its cheating alternative)
I found this surprising and quite disappointing. My question is why following code is allowed and works perfectly? I expected to get error that interface is already implemented explicitly.
This is just basic example to reproduce problem
static void Main(string[] args)
{
var b = new Base();
((IInterface)b).Write();
var c = new Child();
((IInterface)c).Write();
}
public interface IInterface
{
void Write();
}
public class Base : IInterface
{
void IInterface.Write()
{
Console.WriteLine("Base");
}
}
public class Child : Base, IInterface // hack is here. Re Implemented :/
{
void IInterface.Write()
{
Console.WriteLine("Child");
}
}
Outputs
Base
Child
why following code is allowed and works perfectly?
Because the specs say so:
It is a compile-time error for an explicit interface member implementation to include access modifiers, and it is a
compile-time error to include the modifiers abstract, virtual, override, or static.
Yet in polymorphism, the saying goes "the more derived type knows better", from the specs again:
derived classes can extend and specialize base classes
So the most derived type who implements that interface explicitly will be called when you invoke that interface member.
I suggest you to think at the low level translation from C# into native code: the interface inheritance redeclaration, and the one or more of its methods overriding, forces rewriting of the VMT - Virtual Method Table (interface methods are virtual by design).
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.
I am developing an internal class that implements an internal interface.
Can anyone explain why I cannot declare my method as internal, why I am getting the following error: "cannot implement an interface member because it is not public".
I know that I have to declare the method as public, but it makes absolutely no sense to me.
What is the point of declaring a method public if both the interface and the class are internal?
Is it not misleading?
I have read a related question on this site. It is not an exact duplicate, because my class is internal.
Simply put: because that's the way the language designers designed it. Even in internal interfaces, the methods are implicitly public. It does make things simple, but it's a pain in other ways.
If you want a public class where you want to "hide" the use of an internal interface, you could use explicit interface implementation - although that has other drawbacks.
Of course, if your class is internal then it doesn't matter that the methods are public anyway - other assemblies aren't going to be able to call the methods because they can't see the type.
I definitely agree that C# (or .NET in general) hasn't been designed as carefully as it might be around internal interfaces.
In terms of exactly why you're getting an error message - section 13.4.4 of the C# 4 spec (interface mapping) is the reason. Implementations are only found for nonstatic public members and explicit interface member implementations - and if there are any unimplemented members in the interface, an error occurs.
I know this is old but maybe someone find it useful. You can accomplish a kind of internal interface methods like this:
internal interface IFoo
{
void MyMethod();
}
public abstract class Foo : IFoo
{
void IFoo.MyMethod()
{
MyMethod();
}
internal abstract void MyMethod();
}
So all your internal classes should derive from Foo and are forced to implement the abstract MyMethod. But you can treat them all as IFoo of course. But those classes outside the assembly won't provide the MyMethod class.
So you have the advantage to treat your classes internally as IFoo and rely on MyMethod. The drawback is that all your classes will need to derive from Foo which can be a problem if you need another base class.
But I found it helpful if the abstract base class is a generic one and the interface is not. Maybe it is useful in some cases.
I am surprised to know that an abstract class in C# is possible with no abstract methods also.
abstract class AbstractDemo
{
public void show()
{
Console.WriteLine("In Show Method");
}
}
class MainDemo:AbstractDemo
{
public static void Main()
{
Console.WriteLine("In Main Method");
}
}
Any explaination ?
Sometimes you don't want to give the possibility to instantiate a class but you need this class as a base class for other classes.
The reason for choosing abstract classes over interfaces is that you can provide some basic implementation.
This is entirely valid, and occasionally useful if you want to provide event-like behaviour: provide an abstract class with all the "event handlers" implemented as virtual methods with a default behaviour of doing nothing.
I've also personally used this a lot for abstract remote API client classes where all methods throw exceptions: they're abstract for the purposes of test doubles, expecting our implementations to be the only production implementations, but allowing users to create their own test doubles either by hand or via mocking frameworks. Making the methods virtual instead of abstract means that new RPCs can be added without that being a breaking change.
A derived class can then override some of the methods, but doesn't have to override any specific one, because nothing's abstract. It still makes sense for the class to be abstract because an instance of the base class would be pointless (as everything would be a no-op).
This pattern is much more common in Java than C#, however - as in C# you'd normally just use "proper" events.
An abstract class is a class that must be extended before it can be used. This does not it any way mean that the function themselves must be abstract.
Take for example an Animal class
public abstract class Animal
{
void Move()
{
//whatever
}
}
public class Fish : Animal
{
void Swim()
{
}
}
public class Dog : Animal
{
void Bark()
{
}
}
All animals can move but only the fish can swim and the dog can bark.
Or for a real life example. I have an Asp.net MVC base controller I use in my application. It has some basic methods I need very often like GetCurrentUser() and a function I wrote to help with localization. It also takes care of tracking so I don't have to rewrite that code in all of my controllers. The class has about 200 lines of code but not a single abstract method.
I think you're confusing abstract classes with interfaces. Interfaces can't have methods with body, abstract classes can. There are times when you want to prevent user from instantiating an object of a specific class; but still provide some base functionality for the classes that derive from it; this is what an abstract class is useful for.
If your class is just a base for other classes and it does not have an full usablility - in other words as a base itselfe is not usable at all then you want to prevent from creating instances of it. In this case you can make abstract class without abstract members.
You could use abstract keyword on a class just to signal the compiler that it can only used inheriting from it, and not directly; In this case you are not oblied to put abstract member on the class.
This is equivalent to put in the class only one protected constructor, but using abstract is more clear and understandable.
No better explanation than MSDN it self
http://msdn.microsoft.com/en-us/library/aa645615(v=VS.71).aspx
An abstract class cannot be instantiated directly, and it is a
compile-time error to use the new
operator on an abstract class. While
it is possible to have variables and
values whose compile-time types are
abstract, such variables and values
will necessarily either be null or
contain references to instances of
non-abstract classes derived from the
abstract types.
An abstract class is permitted (but not required) to contain abstract
members.
An abstract class cannot be sealed.
We have heard that in abstract class, there must be an abstarct member. But when I compile the abstarct class without an abstract method, it compiles. It gives me surprise. Now I am unable to find the article which explain exact behavior of an abstarct class.
My test code in C#:
namespace DSnA
{
public abstract class Test : IComparable
{
}
}
Results in the following compiler error:
error CS0535: 'DSnA.Test' does not implement interface member
'System.IComparable.CompareTo(object)'
Since the class Test is an abstract class, why does the compiler require it to implement the interface? Shouldn't this requirement only be compulsory for concrete classes?
In C#, a class that implements an interface is required to define all members of that interface. In the case of an abstract class, you simply define those members with the abstract keyword:
interface IFoo
{
void Bar();
}
abstract class Foo : IFoo
{
public abstract void Bar();
}
Or to put it another way: you don't have to "implement" it (which would be a terrible limitation on abstract classes); however, in C#, you do have to tell the compiler that you are deliberately passing the buck to concrete subclasses - and the above line of code shows how to do so.
The comments and downvotes complaining that this is not an answer to the question are missing the point. Someone coming to Stack Overflow, having received this compiler error, but having an abstract class in which it would be a mistake to supply an implementation, are stuck without a good solution - would have to write implementation methods that threw runtime exceptions, a horrendous work-around - until they have the above information. Whether it is good or bad that C# requires this explicitness is outside the scope of Stack Overflow, and not relevant to the question nor this answer.
Unlike Java, in C#:
"an abstract class must provide implementations of all members of the interfaces that are listed in the base class list of the class. However, an abstract class is permitted to map interface methods onto abstract methods."
https://msdn.microsoft.com/en-us/library/Aa664595(v=VS.71).aspx
They don't have to actually implement the interface.The interface methods/properties can be abstract or even virtual as well. So its up to the subclasses to actually implement them.