Pseudo Multiple Inheritance

Question

I have a number of objects that I mapped to a database with LINQ to SQL. Tables are very standardized. I am going to distract from my problem. I have five central objects that I implemented in the database. Then I have a number of other objects that I want to implement with one or all of these five objects.

Suppose I implement a kind of stadium class (think sports teams). These five subjects are five major sports; Baseball, Basketball, Soccer, Hockey, Soccer. I want to explicitly implement a class for each stadium.

This is an example, baseball, hockey and soccer games are held at Yankee Stadium. I want him to implement each of these three interfaces. The StadiumBaseClass is my abstract base class that interacts with my database. The StadiumBaseClass implements all 5 major sports interfaces. I do not want to have the same code to implement the IBaseball interface in all possible stadiums, I want it to be implemented once in the StadiumBaseClass.

In this example, I just want to implement 3, is this the best way to do this? Is it kind of solitary, but not really?

class YankeeStadium : IBaseball, IHockey, IFootball { StadiumBaseClass _Stadium {get; set;} // IBaseball public IBaseball.Whatever {get { return _Stadium.Baseball;} } // IFootball public IFootball.Whatever {get { return _Stadium.Hockey;} } // IHockey public IHockey.Whatever {get { return _Stadium.Hockey;} } } 

Answer 1

Here's an alternative approach (we used something similar, but not sure how much it will fit your linq implementation):

Install each interface with basic functionality on the StadiumBaseClass platform, and then set the virtual properties that the implementation classes can use to: a) indicate which interfaces it supports, and b) change the default behavior as necessary.

For example, assuming the following interfaces:

  public interface IBaseball { void Whatever(); } public interface IHockey { void Whatever(); } public interface IFootball { void Whatever(); } public interface IBasketball { void Whatever(); } public interface ISoccer { void Whatever(); } 

Your base class will look something like this:

  public class StadiumBaseClass : IBaseball, IBasketball, IHockey, IFootball, ISoccer { #region IBaseball Members public virtual bool IBaseballImplemented { get { return false; } } void IBaseball.Whatever() { // Do something } #endregion #region IBasketball Members public virtual bool IBasketballImplemented { get { return false; } } void IBasketball.Whatever() { // Do something } #endregion #region IHockey Members public virtual bool IHockeyImplemented { get { return false; } } void IHockey.Whatever() { // Do something } #endregion #region IFootball Members public virtual bool IFootballImplemented { get { return false; } } void IFootball.Whatever() { // Do something } #endregion #region ISoccer Members public virtual bool ISoccerImplemented { get { return false; } } void ISoccer.Whatever() { // Do something } #endregion } 

Which would leave your individual class stadium:

  class YankeeStadium : StadiumBaseClass { public override bool IBaseballImplemented { get { return true; } } public override bool IHockeyImplemented { get { return true; } } public override bool IFootballImplemented { get { return true; } } } 

Answer 2

I do not think you should use inheritance at all. Instead of the YankeeStadium class, you should have a stadium class with the name.

Similarly, you should have properties like HasHockey OR just the Hockey property returns null if it is not applicable.

Answer 3

This, apparently, is a variant of the general problem of object-oriented modeling - in the past I saw that this created the problem of modeling an educational institution where this Person can be one or more students, teachers, lecturers, Marker, Researcher, etc.

The best solution I've seen is the proposal proposed by Peter Coad and Jeff De Luca as the Nebulon Archetypal Domain Shape , also known as Color Modeling .

In your situation, the actual stadiums will be your Places . Since you want to explicitly implement each stadium as a class, each of them will be a real physical stadium. Having a common abstract base class can be useful. Properties in the class will describe the physical attributes of the stadium - such as the actual address, etc.

Each of the sports that you want to support (you pointed to Baseball, Basketball, Soccer, Hockey and Soccer) will be implemented as a Role class, say BaseballStadium , BasketballStadium , FootballStadium , HockeyStadium and SoccerStadium . Properties on the class will describe specific features regarding the fact that a given sport (the size of the capacity may vary, for example, from one sport to another).

Answer 4

I suggest just having properties in every stadium for every sport so you can call

 Stadium.Baseball.Fixtures Stadium.Hockey.Teams 

When a particular stadium does not allow the sport, return the Null Object , which for this sport;

eg,

 iceRink.Baseball.Available // false iceRink.Baseball.Fixtures // the empty list 

This method will help you avoid multiple inheritance problems, and in particular, code like

 ((IBaseball)stadium).Fixtures 

Answer 5

I think you should take a step back and look at some of the gangs of the four models. This is exactly the situation in which they are intended to demonstrate solutions. I recommend you take a look at the visitor template. The vistior pattern allows multiple items (in your stadiums) to have common behavior performed through them. See here: http://www.dofactory.com/Patterns/PatternVisitor.aspx

The list of gangs of the four models is here: http://www.dofactory.com/Patterns/Patterns.aspx

Perhaps someone else may suggest a different sample to look at. Perhaps the design of the decorator looks promising. (I have not used the decorator pattern before). I think that ultimately you should not fight OO, but rather look for published solutions for your likely common scenario.