Geek Answers Handbook

Implements an interface using a member as a developer

I have a class A that implements IA.
Now I need to create a class B, which should implement IA as well. Class B has an instance of class A as a member.

Is there a way to determine if an instance implements IA in class B?

interfase IA { void method1(); void method2(); . . . . void methodN(); } class A:IA { public void method1(){} public void method2(){} . . . . public void methodN(){} } class B:IA { private IA m_a; public B(IA a) { m_a=a; } //Instead all of this I am looking of a way to define that m_a is the implement to IA of B public void method1(){ use of a.method1 } public void method2(){ use of a.method2 } . . . . public void methodN(){ use of a.methodN } }
+4
source share
7 answers

If B really needs to implement IA , then B must redefine each of the interface methods one by one, even if each implementation is just a call to the implementation of the encapsulated member A

However, there is a lazy way that can prevent you from all this tedious material and which can be considered almost the same from a practical point of view:

 class Program { static void Main(string[] args) { CatOwner Bob = new CatOwner(); Console.WriteLine(((Cat)Bob).Cry); Console.ReadKey(); } } interface ICry { string Cry { get; } } class Cat : ICry { public string Cry { get { return "Meow !"; } } } class CatOwner { private Cat _MyCat; public CatOwner() { _MyCat = new Cat(); } public static implicit operator Cat(CatOwner po) { return po._MyCat; } }

CatOwner does not actually implement Cry , as the owner of the cat is not the one who meows: his cat does. But as an approximation, we could assume that by demanding that the owner of the cat cry, we, of course, imply that this requirement is actually aimed at his cat, and not at the owner himself. Then we “throw the cat owner to his cat,” and then we can make it Cry .

It's pretty funny, no ?:-)

Edit:

However, Magnus's answer is very worth considering IMHO. It looks more logical and cleaner if you pass the member perfectly, given the semantic context. My solution may be interesting if B is just an expanded variety of A that cannot be inherited (sealed) or in such a specific context ... It really depends on the context and semantic restrictions ...

+1
source

Not really, you probably want to define some kind of interface that the IA member returns, for example, the Enumerable / Enumerator template.

 public interface IB { public IA Item { get; } }

Then B can simply return the instance you are storing in it.

 public class B : IB { public IA Item { get; private set; } }

A may even implement IB

 public class A : IA, IB { public void Method1(); //... public void MethodN(); IA IB.Item { get { return this; } } }
+3
source

Deriving B from A is all you need.

 class B:A { public B() { } }
+1
source

Basically, you have two options: inherit from A or encapsulate A This is basically the difference between two design patterns: encapsulation and inheritance .

+1
source

Not sure, but why do you inherit class B from IA? you already have an instance of object A in class B, you can use it ...

0
source

How about opening an "implementer" in a property instead of B that implements the interface.

 class B { public IA Implementer {get; private set;} public B(IA a) { Implementer = a; } }
0
source

Considering your question from a design point of view, this is a completely correct question (in a more complicated real situation), and it would be nice to save many lines of code just saying that the m_a member is the one that implements the entire IA interface in B.

I do not quite agree with the proposals to inherit B from A: 1- in real life, B can inherit from another class that is not related to it, or say that you implement IC and ID, and it would be nice for the m_c and m_d members to specify the implementation of C in m_c and fo ID implementation on m_d..etc. 2- replacement of aggregation by inheritance is usually a bad design.

Good idea though ..

0
source

More articles:


All Articles