Interface C#

[Luuk]

On this page i found an interssting example of an interface:
http://www.c-sharpcorner.com/UploadFile/sekarbalag/interface-best-example-in-csharp/

Here two interfaces are created for a Class named ODDEVEN
The first has methods ONE,THREE,FIVE
The second has methods TWO,FOUR

I was looking at this, and thought i did understand this ;)

So i created another interface SMALLER3 like this:

interface SMALLER3 : IOne,ITwo
{
}


The program:
Console.WriteLine("\n\nThis is SMALLER3");
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266
obj3.TWO();
obj3.ONE();

If fails with:
CS0266 Cannot implicitly convert type 'InterfaceDemo.ODDEVEN' to
'InterfaceDemo.SMALLER3'. An explicit conversion exists

Can someone give a hint to this?

[Arne Vajhøj]

Post by Luuk
http://www.c-sharpcorner.com/UploadFile/sekarbalag/interface-best-example-in-csharp/
Here two interfaces are created for a Class named ODDEVEN
The first has methods ONE,THREE,FIVE
The second has methods TWO,FOUR
I was looking at this, and thought i did understand this ;)
interface SMALLER3 : IOne,ITwo
{
}
Console.WriteLine("\n\nThis is SMALLER3");
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266
obj3.TWO();
obj3.ONE();
CS0266 Cannot implicitly convert type 'InterfaceDemo.ODDEVEN' to
'InterfaceDemo.SMALLER3'. An explicit conversion exists
Can someone give a hint to this?

ODDEVEN class does not implement SMALLER3 so you can not make
that assignment.

The fact that ODDEVEN happens to have all the methods
in SMALLER3 does not matter - it is not required to.

You could add a method SIX to SMALLER3 but not to ODDEVEN.

Arne

PS: Class, interfaces and methods names does not follow common
C# convention.

[Luuk]

Post by Arne Vajhøj

Post by Luuk
http://www.c-sharpcorner.com/UploadFile/sekarbalag/interface-best-example-in-csharp/
Here two interfaces are created for a Class named ODDEVEN
The first has methods ONE,THREE,FIVE
The second has methods TWO,FOUR
I was looking at this, and thought i did understand this ;)
interface SMALLER3 : IOne,ITwo
{
}
Console.WriteLine("\n\nThis is SMALLER3");
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266
obj3.TWO();
obj3.ONE();
CS0266 Cannot implicitly convert type 'InterfaceDemo.ODDEVEN' to
'InterfaceDemo.SMALLER3'. An explicit conversion exists
Can someone give a hint to this?

ODDEVEN class does not implement SMALLER3 so you can not make
that assignment.

I am still learning, and did not notice that i had to add the interface
to this line:
class ODDEVEN : IEVEN, IFive
to make it:
class ODDEVEN : IEVEN, IFive, SMALLER3

Post by Arne Vajhøj
The fact that ODDEVEN happens to have all the methods
in SMALLER3 does not matter - it is not required to.
You could add a method SIX to SMALLER3 but not to ODDEVEN.
Arne
PS: Class, interfaces and methods names does not follow common
C# convention.

as mentioned above, i'm still learning,
so 'common c# convention' is ....... ;)

with change mentioned above things work as i expected,
Thanks.

[Arne Vajhøj]

Post by Luuk

Post by Arne Vajhøj

Post by Luuk
http://www.c-sharpcorner.com/UploadFile/sekarbalag/interface-best-example-in-csharp/
Here two interfaces are created for a Class named ODDEVEN
The first has methods ONE,THREE,FIVE
The second has methods TWO,FOUR
I was looking at this, and thought i did understand this ;)
interface SMALLER3 : IOne,ITwo
{
}

ODDEVEN class does not implement SMALLER3 so you can not make
that assignment.

I am still learning, and did not notice that i had to add the interface
class ODDEVEN : IEVEN, IFive
class ODDEVEN : IEVEN, IFive, SMALLER3

class ODDEVEN : SMALLER3

should do if SMALLER3 extends the other 2 interfaces.

Post by Luuk

Post by Arne Vajhøj
The fact that ODDEVEN happens to have all the methods
in SMALLER3 does not matter - it is not required to.
You could add a method SIX to SMALLER3 but not to ODDEVEN.
PS: Class, interfaces and methods names does not follow common
C# convention.

as mentioned above, i'm still learning,
so 'common c# convention' is ....... ;)

Class name: OddEven

Interface names: IEven, ISmaller3

Method names: One, Two, Three, Four, Five.

Arne

[Jake Bluford]

Just to add a little bit to what Arne has already said... something
that might help with your learning. I actually see two different
types of issues with the code you attempted:

- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).

Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
this:

internal interface SMALLER3 : IEVEN, IFive
{
}

... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

In real world development I doubt you'll run into something like this.
You'd more likely just see something like

var x = new OddEven();

// then you'll call only the methods you need.

[Arne Vajhøj]

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????

InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();

do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????

It will work fine.

Arne

[Jake Bluford]

Post by Arne Vajhøj

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????
InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();
do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????
It will work fine.
Arne

You mean the following will compile for you?



internal interface IOne
{
void ONE();//Pure Abstract Method Signature
}

internal interface ITwo
{
void TWO();
}

internal interface IThree : IOne
{
void THREE();
}

internal interface IFour
{
void FOUR();
}

internal interface IFive : IThree
{
void FIVE();
}

internal interface IEVEN : ITwo, IFour
{
}

internal interface SMALLER3 : IEVEN, IFive
{
}

internal class ODDEVEN : IEVEN, IFive
{
public void ONE()//Implementation of Abstract Method.
{
Console.WriteLine("This is ONE");
}

public void TWO()
{
Console.WriteLine("This is TWO");
}

public void THREE()
{
Console.WriteLine("This is THERE");
}

public void FOUR()
{
Console.WriteLine("This is FOUR");
}

public void FIVE()
{
Console.WriteLine("This is FIVE");
}
}



internal class Program
{
private static void Main(string[] args)
{
Console.WriteLine("This is ODD");

IFive obj1 = new ODDEVEN();

obj1.ONE();

obj1.THREE();

obj1.FIVE();

Console.WriteLine("\n\nThis is EVEN");

IEVEN obj2 = new ODDEVEN();

obj2.TWO();

obj2.FOUR();

Console.WriteLine("\n\nThis is SMALLER3");
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266
obj3.TWO();
obj3.ONE();

Console.ReadLine();
}
}

[Luuk]

Post by Jake Bluford

Post by Arne Vajhøj

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????
InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();
do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????
It will work fine.
Arne

You mean the following will compile for you?
internal interface IOne
{
void ONE();//Pure Abstract Method Signature
}
internal interface ITwo
{
void TWO();
}
internal interface IThree : IOne
{
void THREE();
}
internal interface IFour
{
void FOUR();
}
internal interface IFive : IThree
{
void FIVE();
}
internal interface IEVEN : ITwo, IFour
{
}
internal interface SMALLER3 : IEVEN, IFive
{
}
internal class ODDEVEN : IEVEN, IFive
{

no, this won't compile because you should add the interface SMALLER3
like this:
internal class ODDEVEN : IEVEN, IFive, SMALLER3

But this would be incorrect, because 'SMALLER3' has no connection to the
working of tha interface, and one should not do this.

It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

[Jake Bluford]

Post by Luuk

Post by Jake Bluford

Post by Arne Vajhøj

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????
InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();
do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????
It will work fine.
Arne

You mean the following will compile for you?
internal interface IOne
{
void ONE();//Pure Abstract Method Signature
}
internal interface ITwo
{
void TWO();
}
internal interface IThree : IOne
{
void THREE();
}
internal interface IFour
{
void FOUR();
}
internal interface IFive : IThree
{
void FIVE();
}
internal interface IEVEN : ITwo, IFour
{
}
internal interface SMALLER3 : IEVEN, IFive
{
}
internal class ODDEVEN : IEVEN, IFive
{

no, this won't compile because you should add the interface SMALLER3
internal class ODDEVEN : IEVEN, IFive, SMALLER3
But this would be incorrect, because 'SMALLER3' has no connection to the
working of tha interface, and one should not do this.

Yes but it illustrates the point that I put forth in the prior message
where there was some disagreement, where I stated that

ODDEVEN: IEVEN, IFive and SMALLER3: IEVEN, IFive does not
necessarily make ODDEVEN and SMALLER3 interchangable.

Arne was disagreeing with me on this so I offered this code to make
more clear what I was saying earlier.

Post by Luuk
It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

Actually no, you would not want to call it Interface3, you would want
to call it ISmaller3 or similar. Using a keyword like interface, even
with the case changed, is a bad practice.

[Luuk]

Post by Jake Bluford

Post by Luuk
It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

Actually no, you would not want to call it Interface3, you would want
to call it ISmaller3 or similar. Using a keyword like interface, even
with the case changed, is a bad practice.

You are right about the interface name, 'SMALLER3' is bad,

'Interface3' follows the *rule* that is should stat with an 'I' (but is
also bad)

so, it should have been 'ISmaller3'

[Jake Bluford]

Post by Luuk

Post by Jake Bluford

Post by Luuk
It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

Actually no, you would not want to call it Interface3, you would want
to call it ISmaller3 or similar. Using a keyword like interface, even
with the case changed, is a bad practice.

You are right about the interface name, 'SMALLER3' is bad,
'Interface3' follows the *rule* that is should stat with an 'I' (but is
also bad)
so, it should have been 'ISmaller3'

It brings up another question though, since capital I is used as a
prefix for a naming convention, what if the interface itself really
does begin with an I? For example interfaces corresponding to iron
and magnesium.

IMagnesium // no issue here
Iron // bad name for an interface
IIron // correct name for interface

[Arne Vajhøj]

Post by Jake Bluford

Post by Luuk

Post by Jake Bluford

Post by Luuk
It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

Actually no, you would not want to call it Interface3, you would want
to call it ISmaller3 or similar. Using a keyword like interface, even
with the case changed, is a bad practice.

You are right about the interface name, 'SMALLER3' is bad,
'Interface3' follows the *rule* that is should stat with an 'I' (but is
also bad)
so, it should have been 'ISmaller3'

It brings up another question though, since capital I is used as a
prefix for a naming convention, what if the interface itself really
does begin with an I? For example interfaces corresponding to iron
and magnesium.
IMagnesium // no issue here
Iron // bad name for an interface
IIron // correct name for interface

You would still use I prefix.

Example:

https://msdn.microsoft.com/en-us/library/microsoft.practices.unity.interceptionextension.iinterceptor.aspx

Arne

[Jake Bluford]

Post by Arne Vajhøj

Post by Jake Bluford

Post by Luuk

Post by Jake Bluford

Post by Luuk
It would even be better to name it 'Interface3' (hey, you reader of
this code, try to find out yourself what this interface implements)

Actually no, you would not want to call it Interface3, you would want
to call it ISmaller3 or similar. Using a keyword like interface, even
with the case changed, is a bad practice.

You are right about the interface name, 'SMALLER3' is bad,
'Interface3' follows the *rule* that is should stat with an 'I' (but is
also bad)
so, it should have been 'ISmaller3'

It brings up another question though, since capital I is used as a
prefix for a naming convention, what if the interface itself really
does begin with an I? For example interfaces corresponding to iron
and magnesium.
IMagnesium // no issue here
Iron // bad name for an interface
IIron // correct name for interface

You would still use I prefix.

Agreed (that's what I meant by "// correct name..."). I only posed
the question rhetorically to set up the concept illustration. Your
Unity engine example is a good one.

[Arne Vajhøj]

Post by Jake Bluford

Post by Arne Vajhøj

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????
InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();
do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????
It will work fine.

You mean the following will compile for you?
internal interface SMALLER3 : IEVEN, IFive
{
}
internal class ODDEVEN : IEVEN, IFive
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266

It won't.

But it will if ODDEVEN implements SMALLER3.

Arne

[Jake Bluford]

Post by Arne Vajhøj

Post by Jake Bluford

Post by Arne Vajhøj

Post by Jake Bluford
- One is that by creating an interface (and variable) that contains
only a subset of the total methods, then instantiating it with a class
that contains all the methods, something has been created that should
never compile regardless of language specifics. In some ways you
could think of it as saying create a space in memory that only knows
about and has room for one and two, but in that space lets try to fit
something in that has one two three four and five. It just won't fit.

????
InterfaceWithFewMethods o = new ClassWithManyMethodsInclAllFromInterface();
do work in C# and I believe in all other languages that has
a reasonable support for polymorphism.

Post by Jake Bluford
- Two is exactly what Arne said -- even if both the definition of
SMALLER3 and ODDEVEN did both have the same methods, the interfaces
themselves are not the same. An interface definition has an
identifier behind the scenes, kind of like a primary key of a database
table or the GUID of an object. Conceptually, you could have two rows
in a database table that have equal values in every column, but they
are still not the same row (and if its a reasonably well designed
model, the rows would be differentiated by a primary key), and the
application should never assume they are equal just because they are
at one point in time (because one could change later in a way that
makes it different).
Just as an experiment to and illustrate that point a bit further, try
changing your definition for SMALLER3 to implement IEVEN, IFive like
internal interface SMALLER3 : IEVEN, IFive
{
}
... at this point it might appear more probable that new ODDEVEN() can
allocate an instance that can go in the variable of type SMALLER3. And
why shouldn't they, they implement the exact same methods, right? But
they can't because by creating two different interfaces, we are are in
effect saying "they will likely be different animals at some point,
otherwise we would just use the same interface".

????
It will work fine.

You mean the following will compile for you?
internal interface SMALLER3 : IEVEN, IFive
{
}
internal class ODDEVEN : IEVEN, IFive
SMALLER3 obj3 = new ODDEVEN(); // <-- CS0266

It won't.
But it will if ODDEVEN implements SMALLER3.

Yes but that is a different situation than what I said in my first
message in the thread. I think you misunderstood that message when
you disagreed.

I was trying that if you had:

internal class ODDEVEN : IEVEN, IFive

as well as

internal class SMALLER3 : IEVEN, IFive

... that even though they look like they should be equivalent types
that implement the same methods, it does not make them compatible.

As I said just a misunderstanding. Everything I said agreed with your
first message in thread.