a bit OT: any way to "fake" multiple inheritence with CSLA classes

a bit OT: any way to "fake" multiple inheritence with CSLA classes

Old forum URL: forums.lhotka.net/forums/t/3227.aspx


mtagliaf posted on Thursday, July 19, 2007

I'm implementing baseball Scouting Reports in CSLA classes.  There are 4 types of scouting reports:

Pro, Pitcher
Pro, Position Player
Amateur, Pitcher
Amateur, Position Player

The 2 Pro reports share many common fields as do the 2 Amateur reports. Likewise, the 2 Pitcher reports share many common fields.

I would like to create a subclass hierarchy to implement the reports, but there's no perfect way to do it because I would really like the ReportProPitcher class to inherit off both a ReportPro class and a ReportPitcher class.  This is "multiple inheritence", and it's not allowed in VB.NET

Is there any good way to "fake" it, or a decent design that minimizes some redundant code?

ChristianPena replied on Thursday, July 19, 2007

The stock answer you will likely get is that you should not normalize your objects based on data, but rather upon behavior. So the fact that they share this data does not, in itself, create the need for inheritance/polymorphic behavior.

Data requirements aside, do your objects share anything else in common? If so, then perhaps that commonality represents a third type of object which your existing objects can inherit from. If you are intent on inheriting for the sake of minimize data access code, then you can do the same by having a third class that contains the common data access functionality.

Hope that helps!

Christian

JonStonecash replied on Friday, July 20, 2007

The other way to handle this is to place the common logic in another helper class that is used by the various classes.  This can be more complex than simple inheritance (writing a lot of pass thru delegation methods to connect the outside of each object to the enclosed logic class is a pain) but does allow you to share the common logic. 

I would only advise you to take this approach if the common logic was more than just a few lines of code and you were fairly sure that it was going to stay common.  If it was relatively small or it is likely that it will diverge over time, I would use "copy and paste" inheritance.


Jon Stonecash

Copyright (c) Marimer LLC