Regarding Polymorphism ...

Question regarding polymorphic classes.

Whenever I have a bunch of classes that inherit from the same base class, I generally find I need a way to dynamically invoke them.

For instance, let's say that I have some Components that inherit from GenericFrame and implement IGenericFrame.

The concrete representations could be

DateRangeFrame
DateFrame
UserFrame

The path I typically take is creating a class that I call an Orchestrator with a method GetFrame to handle invoking any of these frames or simply iterate the Orchestrator Dictionary field.

Is there a better way to accomplish this?

It just seems to me that newing up frames that may never get called is wasteful.

public class FrameOrchestrator
{

   private Dictionary<string, Frames.IGenericFrame> _frameList;
   private String _frameName;

   public Dictionary<string, Frames.IGenericFrame> FrameList
   {
      get { return _frameList; }
   }

   public FrameOrchestrator()
   {
      _frameName = String.Empty;
      init();
   }

   public Frames.IGenericFrame GetFrame(string framename)
   {
      if (_frameList.ContainsKey(framename))
      {
         return (Frames.IGenericFrame)_frameList[framename];
      } else {
         return null;
      }
   }

   private void init()
   {
    _frameList = new Dictionary<string, Frames.IGenericFrame>();
     _frameList.Add("DateFrame", new Frames.DateFrame());
   _frameList.Add("DateRangeFrame", new Frames.DateRangeFrame());
   _frameList.Add("UsereFrame", new Frames.UserFrame());
   }

}

Why not use a factory?

gabe19 wrote:

Why not use a factory?

I dunno, I was hoping you would tell me :O

I just always thought factories over complicated things, as the only good example I have seen was overly complicated.

The other issue is that I probably don't know until runtime what type of object I want. So 

         factory = new ConcreteFactoryA();
        prodA = factory.CreateProductA();

Wouldn't really work for me.


Other factory examples I have seen used methods I would rather not incoporate such as using reflection to load an assembly from a string name.

Got a decent C# factory sample?

You could also perform lazy-loading. And instead of using a string as key, you can use the type itself:

public class FrameOrchestrator
{
   Dictionary<Type, Frames.IGenericFrame> _frames = new Dictionary<Type, Frames.IGenericFrame>();
   

   public Frames.IGenericFrame GetFrame<T>() where T:Frames.IGenericFrame, new()
   {
      Type type = typeof(T);
      Frames.IGenericFrame frame;
      if (!_frames.TryGetValue(type, out frame))
      {
         frame = new T();
         _frames[type] = frame;
      }
      return frame;
   }

}

Example:

Frames.IGenericFrame f = orchestrator.GetFrame<Frames.DateFrame>();

TommyCarlier wrote:



You could also perform lazy-loading. And instead of using a string as key, you can use the type itself:

public class FrameOrchestrator
{
   Dictionary<Type, Frames.IGenericFrame> _frames = new Dictionary<Type, Frames.IGenericFrame>();
   

   public Frames.IGenericFrame GetFrame<T>() where T:Frames.IGenericFrame, new()
   {
      Type type = typeof(T);
      Frames.IGenericFrame frame;
      if (!_frames.TryGetValue(type, out frame))
      {
         frame = new T();
         _frames[type] = frame;
      }
      return frame;
   }

}

Example:

Frames.IGenericFrame f = orchestrator.GetFrame<Frames.DateFrame>();

Very nice.
Easy to read and uncomplicated, I love it!

TommyCarlier wrote:



You could also perform lazy-loading. And instead of using a string as key, you can use the type itself:

public class FrameOrchestrator
{
   Dictionary<Type, Frames.IGenericFrame> _frames = new Dictionary<Type, Frames.IGenericFrame>();
   

   public Frames.IGenericFrame GetFrame<T>() where T:Frames.IGenericFrame, new()
   {
      Type type = typeof(T);
      Frames.IGenericFrame frame;
      if (!_frames.TryGetValue(type, out frame))
      {
         frame = new T();
         _frames[type] = frame;
      }
      return frame;
   }

}

Example:

Frames.IGenericFrame f = orchestrator.GetFrame<Frames.DateFrame>();

Correct me if I'm wrong, but the only reasons you need this sort of complexity are:

1. You want only a single instance of each frame type.
2. You want to be able to enumerate all of the instantiated frames.

These are the only two things you gain over simply calling the constructors of the frames when you need them.

Also, the (potential) problem I see with relying on the type as the instantiation key is that your caller now needs a reference to the concrete implementations of the frames.  If that's a problem, then you need to rely on a type name and dynamically create an instance of the type based on the name when necessary.

I thought that was the purpose: to have only a single instance of each type. You're right, that the caller needs a reference to the implementation, but you could also consider it an advantage: now you have a compile-time check. If you use a string, and you make a typo, the compiler won't be able to catch it, and you'll get an exception the first time you use that string. And you have intellisense.

TommyCarlier wrote:

I thought that was the purpose: to have only a single instance of each type. You're right, that the caller needs a reference to the implementation, but you could also consider it an advantage: now you have a compile-time check. If you use a string, and you make a typo, the compiler won't be able to catch it, and you'll get an exception the first time you use that string. And you have intellisense.

Quite right.
Don't really care about the ref requirement, however instantiating a frame from an orchestrator in my example facilitates capabilities like:

this._currentFrame = _frameOrchestrator.GetFrame(cboFrame.SelectedItem.ToString());

if (_currentFrame != null)
{
   Control loadedControl = (Control)_currentFrame;
   loadedControl.Dock = DockStyle.Fill;
}

   this.pnlFrameContainer.Controls.Add((Control)_frameOrchestrator.GetFrame(cboCriteriaCombo.SelectedItem.ToString()));