Multiple inheritance in C# properties (or function parameters)

This situation: you have defined multiple interfaces (for example: IMyInterface1, IMyInterface2, ...). In the class MyClass has a property IMyInterface MyProperty { get; set; }.

I would like, to property have implemented two-three interface (roughly as this may make the grade) without losing strong typing.

As far as I know the C# syntax does not allow it. To create each set of interfaces of a particular type do not want (will be too many combinations). Create a bunch of properties, each of which implements a separate interface is also really awkward.

Inheritance of interfaces does not propose to discuss, as it is not good (inherit only effective way to avoid code duplication). The interfaces are independent.

Got any suggestions?



 interface IClickableButton
{
 event Action Click;
}

 interface IColorButton
{
 Color Color { get; set; }
}

 class MyForm
{
 public IClickableButton ClickableButton { get; set; }
 public IColorButton ColorButton { get; set; }
 public <iclickablebutton, icolorbutton> ClickableColorButton { get; set; }
}
</iclickablebutton,>


There are two interfaces: the "Nimalasena and Tsvetanka". I want a property "Nimalasuriya" class "Maform" somehow implement both of these interfaces.

Now I have to make two separate properties. How to combine them into one? (code <icolorbutton, icolorbutton> ClickableColorButton { get; set; }</icolorbutton,> not a ride, for clarity written)

P. P. S.:

Eventually came to the question "why it might be needed?" I agree — the problem is rare. And goal one — decrease the interconnection of blocks of code.

Let's say we create classes of controllers that control the user interface forms. Controllers are not working directly with classes, and through the interface. In most cases, the controller can simply sign up for the press event of "Nimbusivonne" and handle it. But one of the twenty controllers, for example, not only handles the click, but have to change the color of the button. And a couple of controllers except per click should change the text on the button. Of course, you can create an interface directly with the "click", "color" and "text". But the greater part of the controllers of the other properties do not need — they need only click. Here arises a problem — how to transfer the properties "color" or "text" only in those rare cases when they are truly needed.

And one more thing — if the code is covered by unit tests — as an experimental object, you may need to slip the mock-I. the simpler interfaces, the easier it is these mock-objects forming.

Perhaps someone will say that it is unnecessary abstraction, too detailed — perhaps... But I'm interested in here — is there a possibility. And to what extent to use it is another question.

P. P. P. S.: suitable decision for me is described here: habrahabr.ru/blogs/net/123229 While writing a topic, the user tenbits suggested exactly the same solution.
October 10th 19 at 03:53
9 answers
October 10th 19 at 03:55

interface IMyInterface1
{
 string Prop1 {get;set;}
 string Prop2 {get;set;}
}

interface IMyInterface2
{
 string Prop1 {get;set;}
 string Prop3 {get;set;}
}

class MyClass : IMyInterface1, IMyInterface2
{
 string Prop1 {get; set } // Shared property
 string Prop2 {get; set }
 string Prop3 {get; set }
}

You this situation mean? If Yes, then you can do that. The property Prop1 is going to implement 2 interface.
Not really.

Then I see implicit inheritance of interfaces (it would be possible to allocate a property Prop1 in interface IMyInterface0, and from it to inherit IMyInterface1 and IMyInterface2). But even in this case, the property Prop1 does not implement two interface (type is string).

And I want a property Prop1 implemented simultaneously IMyInterface1 and IMyInterface2. - Heath_Bogisich9 commented on October 10th 19 at 03:58
But even in this case, the property Prop1 does not implement two interface (type is string).

Something I did not understand. How are the type and properties of the interface implementation?

In the example that I wrote Prop1 one implements both interfaces:

var C = new MyClass();
(c as IMyInterface1).Prop1 = "Hello";
(c as IMyInterface2).Prop1 = "World";

The example shows that the class MyClass realize both interfaces. - jocelyn_Dickens commented on October 10th 19 at 04:01
Here's a look: msdn.microsoft.com/en-us/library/ms173157.aspx - jocelyn_Dickens commented on October 10th 19 at 04:04
I just don't want for every combination of interfaces to produce classes. - Heath_Bogisich9 commented on October 10th 19 at 04:07
October 10th 19 at 03:57
After clarification of the question became a little clearer. Try using dynamic to do:

public dynamic ClickableColorButton { get; set; }

Thus, You will be able to put in ClickableColorButton desired object, and then in the runtime to call methods from different interfaces.
Thanks, I try... Although, as I understand it, at the expense of losing strong typing - Heath_Bogisich9 commented on October 10th 19 at 04:00
Lost. But honestly, I don't see any other way. By the way, dynamic is only .NET 4.0. - jocelyn_Dickens commented on October 10th 19 at 04:03
October 10th 19 at 03:59
Alas, it does not, as far as I know.
October 10th 19 at 04:01
Understand that you may be aware, but just in case.
Can you Explicit Interface Inheritance?

interface IMyInterface1<br> {<br> string Prop1 {get;set;}<br> string Prop2 {get;set;}<br> }<br> <br / > interface IMyInterface2<br> {<br> string Prop1 {get;set;}<br> string Prop3 {get;set;}<br> }<br> <br / > class MyClass : IMyInterface1, IMyInterface2<br> {<br> string IMyInterface1.Prop1 {get; set }<br> string IMyInterface2.Prop1 {get; set }<br> string Prop2 {get; set }<br> string Prop3 {get; set }<br> }
Again, there are properties of type string. I need one property to implement multiple interfaces.
Perhaps I not clearly formulated task. Now I'll try to clarify. - Heath_Bogisich9 commented on October 10th 19 at 04:04
To clarify the issue - jocelyn_Dickens commented on October 10th 19 at 04:07
October 10th 19 at 04:03
Maybe you can fit something like:
class MyForm<br> {<br> public IClickableButton ClickableButton { get{return ClikableColorButton; }}<br> public IColorButton ColorButton { get {return ClickableColorButton; }}<br> public ClickableColorButton ClickableColorButton { get; set; }<br> }<br>
you cannot return a reference to on 2 interface, because the class may have a different implementation of the same method for different interfaces and in this case it is not clear which method should be implemented.
I understand that the author of the question just does not want to produce the interfaces. - Heath_Bogisich9 commented on October 10th 19 at 04:06
It is proposed to create a class that implements the necessary interfaces, and set its type properties. If the interface only two is the output. But if the interfaces of two dozen bored these classes sculpt... - jocelyn_Dickens commented on October 10th 19 at 04:09
What is planned to return if there is no class that implements all increase? You can't instantiate an interface. - jocelyn_Dickens commented on October 10th 19 at 04:12
Of course, in reality, the property will be a class that implements all the necessary interfaces. But I would like the signature to indicate only those interfaces that really need to work, and not merge all into one magazinehas containing hundreds of properties. - Heath_Bogisich9 commented on October 10th 19 at 04:15
October 10th 19 at 04:05
In my opinion, you are not fully thought through how you want to use. You still will have to create an object of a class that inherits both interfaces, and, therefore, create a class ColorClickableButton: IClickableButton, IColorButton.

In any case, you might help design like this:
public class MyForm<t> where T : IClickableButton, IColorButton
{
 T Button { get; set; }
}
</t>
And yet — read the comments to this article. - Heath_Bogisich9 commented on October 10th 19 at 04:08
Described the problem in more detail in P. PS: - jocelyn_Dickens commented on October 10th 19 at 04:11
I think the solution described in the article to which I have above given link solves your problem. - jocelyn_Dickens commented on October 10th 19 at 04:14
Yes, thank you, the article in the subject - Heath_Bogisich9 commented on October 10th 19 at 04:17
October 10th 19 at 04:07
And you can use the dump:
 private static readonly Dictionary<type, object> Dump = new Dictionary<type, object>();
 public T Get<t>() where T : class
{
 return Dump.ContainsKey(typeof(T)) ? Dump[typeof(T)] as T : default(T);
}
 public void Set<t>(T value) where T : class
{
 Dump[typeof(T)] = value;
}
</t></t></type></type>
I would like to preserve strong typing. - Heath_Bogisich9 commented on October 10th 19 at 04:10
Oh, zaminusovali ;) But surprising — deserved.
At the expense of your p.p.s:
Can you make the export necessary interfaces, via the tuple(System.Tuple(4.0))
public Tuple<t1,t2> Export() where T1: class where T2 class
{
 return new Tuple<t1,t2>(){ Item1 = this as T1, Item2 = this as T2}
}
</t1,t2></t1,t2>

(the analog for a set with 3 interfaces)
Well, for example abstract class user:
public class NameColorManager
{
 private Tuple<icolor,iname> _tuple;
 public NameColorManager(GlobalManager m)
{
 _tuple = m.Export<icolor,iname>();
_tuple.Item1.SetColor(Color.White);
}
</icolor,iname></icolor,iname>


It's all as options. Good or bad you be the judge... - jocelyn_Dickens commented on October 10th 19 at 04:13
while I wrote the topic, You suggested exactly the same solution. Offer to make authorship in half :) Plus in karma! - jocelyn_Dickens commented on October 10th 19 at 04:16
October 10th 19 at 04:09
In the current version of C# preserving strong typing — no way. C# does not allow you to inherit from a generic parameter. Something like interface IDoubleInterface: I1, I2 {} won't work. Without generics — strong typing will not.

Not sure how the situation is from the P. P. S. life, but it is the issue of connectivity needs to be solved at a different level.
IMO, you should not even think about the segregation of the interfaces of the individual controls when each controller receives a form with 50 fields, and can work with all its elements, whatever. Try to select the interfaces from the form itself — perhaps many of the controllers do not overlap on the usable properties.
> do not even think about the segregation of the interfaces of the individual controls when each controller receives a form with 50 fields, and can work with all its elements, whatever. Try to select the interfaces from the form itself — perhaps many of the controllers do not overlap on the usable properties.

Uh... don't quite understand. Can you give me other words? - Heath_Bogisich9 commented on October 10th 19 at 04:12
Are you trying to hide the button methods for the interfaces ICliсkableButton. And you hide the very existence of buttons for the event SaveClicked interface IMyForm.
Imagine that tomorrow the design will change, and instead of a button there will be a link that ICliсkableButton does not implement. The need to change the controller and is a sign of high relatedness. The problem of high connectivity are not in the visibility properties. And that in your version of the controller will be forced to change when non-functional changes to the form. - jocelyn_Dickens commented on October 10th 19 at 04:15
Yes, about button — agree. But about the button — it's just an example. I had this situation with the data providers — they contain a bunch of properties/methods, and I tried to cut more easily. For example, was a provider of SQL database which had hundreds of methods to access the different tables had to allocate interfaces to work with different entities (each interface contained dozens of methods, it turned out several of these interfaces). But then I had to pass on these interfaces in the business layer by transferring, and it has something not very nice. - jocelyn_Dickens commented on October 10th 19 at 04:18
October 10th 19 at 04:11
The example DB is not very clear without the code. It is unclear, why was it necessary to list the interfaces in the business logic. Probably you could try something like IoC/DI and refleksy to register all interfaces in the IoC container.
The solution Tuples are good. But I would like to understand what specific architectural problem it solves better than other methods.
I suggest to wait for review in habratopike.

Find more questions by tags .NETC#OOP