c # interfaces limitations ???

[rajkumar]

Hey all

Here is my question Consider two classes

Class A : SomeSystemClassA

Class B : SomeSystemClassB
Now I have to add a common interface to both class A and class B. The
way A and B are derived I cannot add a common abstract base class for
them.

So I do

Class A : SomeSystemClassA, ICommonInterface

Class B : SomeSystemClassB, ICommonInterface

The problem I am facing is that C# doesn't allow interfaces to have
static functions or for that matter any function implementation (unless
I am missing something )

In a scenario like this if ICommonInterface had 10 funcs chances are A
and B contain 3 functions that are exactly the same resulting in code
duplication in A and B

How can this problem be solved? Is there a way better than this method?

Have a CommonInterfaceImplClass property on ICommonInterface and in
class A and B have all methods dispatch the call to
CommonInterfaceImplClass.

Class A
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Class B
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Still code duplication but not a maintenance nightmare.

[Dan Bass]

Interfaces are not a C# concept, they're an Object Oriented principle.

Interfaces are purely abstract. That is they do not contain any
implementation or data members.

In your case I'd do the following:

IAnimal (interface)
- all the function declarations that are required for a concrete
implementation of the object go here

Mammal : IAnimal (abstract class)
- if there are shared functions between two children they are
implemented here...

Cat : Mammal (concrete class)
Dog : Mammal (concrete class)
- uses functions found in Mammal, but has its own instantiations.
Hope that helps.

Daniel.


<ra******@hotmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Hey all

Here is my question Consider two classes

Class A : SomeSystemClassA

Class B : SomeSystemClassB
Now I have to add a common interface to both class A and class B. The
way A and B are derived I cannot add a common abstract base class for
them.

So I do

Class A : SomeSystemClassA, ICommonInterface

Class B : SomeSystemClassB, ICommonInterface

The problem I am facing is that C# doesn't allow interfaces to have
static functions or for that matter any function implementation (unless
I am missing something )

In a scenario like this if ICommonInterface had 10 funcs chances are A
and B contain 3 functions that are exactly the same resulting in code
duplication in A and B

How can this problem be solved? Is there a way better than this method?

Have a CommonInterfaceImplClass property on ICommonInterface and in
class A and B have all methods dispatch the call to
CommonInterfaceImplClass.

Class A
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Class B
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Still code duplication but not a maintenance nightmare.

[Dan Kelley]

Static methods on an interface would not really make sense. An interface is a
contract, which the implementor must support.

In your scenario, where you acnnot use implementation inheritance to provide
the functionality for common methods, you could instead create a separate
class which provides this functionality. Each class that implements your
interface could then have a private instance of this class. The interface
implemented methods could then call into this class.

HTH
Dan

"ra******@hotmail.com" wrote:

Hey all

Here is my question Consider two classes

Class A : SomeSystemClassA

Class B : SomeSystemClassB
Now I have to add a common interface to both class A and class B. The
way A and B are derived I cannot add a common abstract base class for
them.

So I do

Class A : SomeSystemClassA, ICommonInterface

Class B : SomeSystemClassB, ICommonInterface

The problem I am facing is that C# doesn't allow interfaces to have
static functions or for that matter any function implementation (unless
I am missing something )

In a scenario like this if ICommonInterface had 10 funcs chances are A
and B contain 3 functions that are exactly the same resulting in code
duplication in A and B

How can this problem be solved? Is there a way better than this method?

Have a CommonInterfaceImplClass property on ICommonInterface and in
class A and B have all methods dispatch the call to
CommonInterfaceImplClass.

Class A
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Class B
{
Void CommonFunc1()
{
CommonInterfaceImplClass. CommonFunc1()
}
}
Still code duplication but not a maintenance nightmare.

[Dan Bass]

> In your scenario, where you acnnot use implementation inheritance to

provide
the functionality for common methods, you could instead create a separate
class which provides this functionality. Each class that implements your
interface could then have a private instance of this class. The interface
implemented methods could then call into this class.

While this is not wrong. The fact that the classes have code in common
suggests it to be something pertaining to that object. If this is the case,
then the object orientated way would be to have the code refactored out, and
placed into a class that is a sub set of these objects. Hence creating an
intermediate layer, parenting the concrete classes, but a child of the
interface.

Creating a global class dumping ground isn't a clean or clear way of showing
what you're trying to do. While a few methods used by a couple of sibling
classes doesn't donote this scenario, it's an easy habit to get into where
every time you want to reference some common code, it goes into some large
class.

[rajkumar]

I think you missed my question totally. I already have something like
this. Now I want Cat and Dog to implement IPettable interface. I
cannot add it at Mammal because not all Mammals are pettable.

so if I do

Cat : Mammal , IPettable
Dot: Mammal , IPettable

Now Cat and Dog have to implement all IPettable methods and I am
finding some methods are exactly the same in Cat and Dog class

IPettable
{
reactToPetting()
LookAtOwnerLovingly()
}

Dog
{

reactToPetting()
{
Woof()
LookAtOwnerLovingly()
}

}

Cat
{

reactToPetting()
{
Purr()
LookAtOwnerLovingly()

}

}

In this case reactToPetting() needs to be different but
LookAtOwnerLovingly() method for class Dog and Cat are doing
essentially the same thing

Raj

[rajkumar]

Unless I am missing something it looks exactly like what i proposed in
the original post

[Joanna Carter \(TeamB\)]

<ra******@hotmail.com> a écrit dans le message de news:
11*********************@z14g2000cwz.googlegroups.c om...

In a scenario like this if ICommonInterface had 10 funcs chances are A
and B contain 3 functions that are exactly the same resulting in code
duplication in A and B

How can this problem be solved? Is there a way better than this method?

Write a delegate class that implements the common interface methods and
simply write redirection methods in each class that requires that
functionality.

////////////////////////////////////
interface IMyInterface
{
void Method1();
void Method2();
}

public class MyIntfDelegate
{
void Method1()
{
...
}

void Method2();
{
...
}
}

public class UsesDelegate : IMyInterface
{
private MyIntfDelegate delegate = new MyIntfDelegate();

void IMyInterface.Method1()
{
delegate.Method1();
}
void IMyInterface.Method2()
{
delegate.Method2();
}
}
////////////////////////////////

Joanna

--
Joanna Carter
Consultant Software Engineer

[rajkumar]

Unless I am missing something it looks exactly like what i proposed in
the original post ..........Not again

[Bruce Wood]

Not quite. The suggestion is to create a PettableMammal class that is a
child class of Mammal and implements IPettable, and derive Dog and Cat
from that.

Of course, this works for only one interface, and only in certain
situations, so the general answer to your question is no, there is no
solution other than the one you outlined.

Multiple inheritance was omitted from C# because of the problems that
it causes in C++ (the "diamond problem" and all that), and as Anders
Hejlsberg put it, "You almost never really need it."

I find that the only significant problem that single inheritance /
interfaces cause in C# (and Java) is the pressure to make interfaces
simple--weak, if you will. The developer tends to under-design
interfaces knowing that every new bit of functionality has to be
implemented "n" times. Of course, the resulting interfaces are often
adequate, but could be better.

[rajkumar]

Well java doesn't have the same problem though...one can implement
multiple interfaces like C# but they let you have default implemenation
in the interface class.

This way when one implements an interface one only needs to override
the methods one needs.

[Jon Skeet [C# MVP]]

<ra******@hotmail.com> wrote:

Well java doesn't have the same problem though...one can implement
multiple interfaces like C# but they let you have default implemenation
in the interface class.
No they don't. From the JLS:

<quote>
An interface declaration introduces a new reference type whose members
are classes, interfaces, constants and abstract methods. This type has
no implementation, but otherwise unrelated classes can implement it by
providing implementations for its abstract methods.
</quote>

If you really believe Java interfaces can provide implementations,
please give some example code showing this. You won't be able to.
This way when one implements an interface one only needs to override
the methods one needs.

Nope.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Joanna Carter \(TeamB\)]

<ra******@hotmail.com> a écrit dans le message de news:
11**********************@l41g2000cwc.googlegroups. com...

Unless I am missing something it looks exactly like what i proposed in
the original post ..........Not again

That's because there really is no other way :-)

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

[Bruce Wood]

Not the Java I knew... but then it may have changed in the last two
years. :)

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

Not the Java I knew... but then it may have changed in the last two
years. :)

It has, but not in that respect.

(I find it amazing how many times people on .NET newsgroups claim that
Java works in some way that it doesn't...)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too