0

I am building a relatively simple app and a little bit confused on a better practice of design.

I have a main class MClass. Classes Child1 and Chil2 both inherit from MClass. Now, there is another class AClass, which can inherit from either Child1 or Child2, but not both at the same time (which is only possible through, I believe, interface).

How do I go about having this optional inheritance from one or the other class?

There are also classes AChild1 and AChild2, which both inherit from AClass. The end result would be as follows:

MClass:Child1:AClass:AChild1

MClass:Child2:AClass:AChild2

These are the only two options possible. Is it better to simply combine AClass with its children having

MClass:Child1:AClass1

MClass:Child2:AClass2

I could do this but AClass1 and AClass2 would have a lot of redundant fields... Any reccomendations?

Thank you!

EDIT:

Here is a specific situation:

I have a piece of Equipment that can be either Type1 or Type2. Class Equipment has a bunch of properties. Type1 and Type2 have their own properties and they inherit from Equipment. Both Type1 and Type2 have cables. There is a class Cable with specific properties. In addition, Type1 and Type2 have different types of cables, CableType1 CableType2, which have their own specific properties and inherit fields from either Type1 or Type2.

Improve this question
2
  • whats the prob with MClass:Child1:AClass:AChild1 MClass:Child2:AClass:AChild2 Commented Mar 20, 2013 at 19:42
  • It does not work, AClass cannot inherit from both Child1 and Child2 at the same time. Commented Mar 20, 2013 at 19:46

2 Answers 2

Reset to default
3

VB.NET does not allow multiple inheritance. Depending on your concrete use case, there are various things you can do:

  • Describe common functionality between the classes in interfaces. Of course you still need to implement the functionality in all classes separate and it does not help you with fields, but you can use a shared interface to access all classes that provide the functionality.
  • Put the functionality in the child classes like you suggested. This is possible but would mean some duplicate fields. In some cases this might be okay, in other cases not.
  • Put the functionality in the common base class MClass. Again this depends on the concrete scenario
  • Use composition over inheritance. The need for multiple inheritance often indicates a bad class design where the inheritance relationship ("is a") is misused and you really want to express a composition ("has a"). This would meaning putting the fields and/or methods in a separate class which is used by both childs. You should use the Single responsibility principle as a guidance, so that each of the classes has only one clearly defined responsibility.

Unfortunately you did not give us a concrete example, so it's difficult to say what would be best in your case. Quite possible a combination of these techniques will lead to best results.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I went with putting the functionality in the child classes. Not the most elegant solution but simple is usually good...
An equipment IS NOT a cable, it HAS cables, so you should use composition in this case. Have a property "Cable" in your class which contains the separate cable class for example or something similar.
@aKzenT: A typical piece of equipment is not a Cable, but some types of equipment may not only have, but be, things-that-connects-other-things, perhaps otherwise known as an IConnectables.
1

As someone has already mentioned, .NET does not support multiple inheritance. That being said, a class can implement multiple interfaces, or an interface can inherit multiple interfaces, which in conjunction with extension methods provides a nice way to share implementation. This isn't as analogous to multiple inheritance as it is to a mixin, but the effect is largely the same.

If you rethink your model in terms of interfaces, you can do what you want in terms of multiple inheritance. The implementation classes would just be POCO's, and the implementation logic would be static methods in the form of extension methods.

For encapsulation, you can implement certain properties on the implementation class using explicit interface implementation, so that certain properties aren't visible when working with the class itself.

I've found that using this technique helps a lot with testability and prevents a lot of coupling.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.