using Interface and abstract classes

[Tony Johansson]

Hello!!

Assume you have an Interface called ITest with these three method
declarations.
interface ITest
{
void foo1();
void foo2();
void foo3();
}

Assume that you "inherit" this interface to an abstract class called ABCBase
like this.
abstract public class ABCBase : ITest
{
//Here you add some more.
abstract public void goo1();
abstract public void goo2();
abstract public void goo3();

abstract public void foo1();
abstract public void foo2();
abstract public void foo3();
}

Below we have class RealClass that implements all six methods that must be
implemented.
Now to my question I have noticed that I must redeclare all three from the
interface like this
abstract public void foo1(); abstract public void foo2(); abstract public
void foo3();
in the abstract ABCBase class despite having a definition in the RealClass.
Does it really have to be in that way. In a way it feels unnessessary to do
this. Is this a misstake in
the construction of C# having to declare methods in the abstract class when
the same method exist in the interface.

My next question is it common to have this construction with an interface
then an abstract class
that "inherit" and finally the the real class that make the method
definitions.
public class RealClass : ABCBase
{
void foo1()
{//some code here }

void foo2()
{//Some code here}

void foo3()
{//some code here}
void goo1()
{//some code here }

void goo2()
{//Some code here}

void goo3()
{//some code here}
}

//Tony

[Lebesgue]

First of all, your code would not compile, since you are not overriding the
abstract methods in your RealClass (missing override keyword).

Yes, you have to declare the methods from interface as abstract methods in
your abstract class and this is a common practice.

Maybe this article would give you some insight:
http://msdn.microsoft.com/msdnmag/is...12/NETMatters/

"Tony Johansson" <jo*****************@telia.com> wrote in message
news:cy*******************@newsb.telia.net...

Hello!!

Assume you have an Interface called ITest with these three method
declarations.
interface ITest
{
void foo1();
void foo2();
void foo3();
}

Assume that you "inherit" this interface to an abstract class called
ABCBase like this.
abstract public class ABCBase : ITest
{
//Here you add some more.
abstract public void goo1();
abstract public void goo2();
abstract public void goo3();

abstract public void foo1();
abstract public void foo2();
abstract public void foo3();
}

Below we have class RealClass that implements all six methods that must be
implemented.
Now to my question I have noticed that I must redeclare all three from the
interface like this
abstract public void foo1(); abstract public void foo2(); abstract public
void foo3();
in the abstract ABCBase class despite having a definition in the
RealClass.
Does it really have to be in that way. In a way it feels unnessessary to
do this. Is this a misstake in
the construction of C# having to declare methods in the abstract class
when the same method exist in the interface.

My next question is it common to have this construction with an interface
then an abstract class
that "inherit" and finally the the real class that make the method
definitions.
public class RealClass : ABCBase
{
void foo1()
{//some code here }

void foo2()
{//Some code here}

void foo3()
{//some code here}
void goo1()
{//some code here }

void goo2()
{//Some code here}

void goo3()
{//some code here}
}

//Tony

[Nick Hounsome]

Your problem is that you are thinking like a C++ programmer: interfaces are
not just classes with abstract methods - You don't inherit interfaces in C#
you implement them.

What you are saying is that ABCBase implements ITest......but it doesn't so
you have to make a derived class do it for you hence the abstract.

I do agree that it is a bit odd though.

"Tony Johansson" <jo*****************@telia.com> wrote in message
news:cy*******************@newsb.telia.net...

Hello!!

Assume you have an Interface called ITest with these three method
declarations.
interface ITest
{
void foo1();
void foo2();
void foo3();
}

Assume that you "inherit" this interface to an abstract class called
ABCBase like this.
abstract public class ABCBase : ITest
{
//Here you add some more.
abstract public void goo1();
abstract public void goo2();
abstract public void goo3();

abstract public void foo1();
abstract public void foo2();
abstract public void foo3();
}

Below we have class RealClass that implements all six methods that must be
implemented.
Now to my question I have noticed that I must redeclare all three from the
interface like this
abstract public void foo1(); abstract public void foo2(); abstract public
void foo3();
in the abstract ABCBase class despite having a definition in the
RealClass.
Does it really have to be in that way. In a way it feels unnessessary to
do this. Is this a misstake in
the construction of C# having to declare methods in the abstract class
when the same method exist in the interface.

My next question is it common to have this construction with an interface
then an abstract class
that "inherit" and finally the the real class that make the method
definitions.
public class RealClass : ABCBase
{
void foo1()
{//some code here }

void foo2()
{//Some code here}

void foo3()
{//some code here}
void goo1()
{//some code here }

void goo2()
{//Some code here}

void goo3()
{//some code here}
}

//Tony

[Jeff Louie]

You just need to look at the problem a bit differently. In C++ ITest
would be a
pure virtual class and RealABC would inherit from both ABCBase and ITest
using
C++ support for multiple inheritance. C# supports single inheritance of
implementation and multiple inheritance of interfaces or pure virtual
classes. So
you could just have RealABC "inherit" from ABCBase and "implement"
ITest. If
ABCBase has no implementation details then in C# you would create two
interfaces IABC and ITest and RealABC would implement IABC and ITest.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Tom Porterfield]

On Sat, 22 Apr 2006 16:08:40 GMT, Tony Johansson wrote:

Does it really have to be in that way. In a way it feels unnessessary to do
this. Is this a misstake in
the construction of C# having to declare methods in the abstract class when
the same method exist in the interface.

An Interface is only a contract, one that says that any class that
implements the interface must implement all methods/properties defined in
the interface. If you class, abstract or not, is going to implement an
interface, then it must implement the entire interface. It's not a
mistake.
--
Tom Porterfield

[Bruce Wood]

> Is this a misstake in the construction of C# having to declare methods

in the abstract class when the same method exist in the interface.

No, in fact it's by intelligent design that you must explicitly say
that you are leaving the methods abstract instead of leaving it as an
implicit assumption. Think about what would happen if you could leave
those abstract declarations out.

In the class RealClass, you would be overriding methods but it wouldn't
be clear just where you were overriding them from, because they would
appear nowhere in ABCBase, and RealClass would have no direct reference
to ITest.

In the class ABCBase, you would apparently be implementing the
interface ITest, but you would never explicitly say what you were doing
about its methods. If goo1, goo2, and goo3 weren't abstract in ABCBase,
it wouldn't be clear why ABCBase was abstract.

Yes, if you noticed the ": ITest" after ABCBase, everything would be
clear, but the syntax required by C# makes things completely explicit.
This way, ABCBase must explicitly state that yes, it is leaving the
methods in ITest to be implemented by derived classes.

Furthermore, if you add a new method to ITest at some point in the
future, it is ABCBase that will fail to compile, which is what you
would want: the consideration of what to do about an addition to the
interface must start back at ABCBase, which can choose to either
implement the new method or make it abstract, which then passes the
problem to derived classes. By eliminating implicit assumptions, the
language deals more gracefully with change.