   C# - Adding a concrete method to an interface
  I am working with objects that need to be linked together modularly (for DSP) - these objects inherit interfaces.IElement is an element within the system; its only abstract method is Config which is used to show an interface to the user to configure the elementIOutputEnabled denotes an element that has an output that can be routed to some other element; it's only abstract method is Output.IInputEnabled denotes an element that has inputs available for connection. It has two methods, one which is GetAvailInputs and returns a list of strings, which are keys to a hashtable of connections on the Input machine; and the other abstract method is Connect(IOutputEnabled, string input) which will connect an IOutputEnabled object to the IInputEnabled object.Now the problem is, I want to have a consistent UI for managing the connections - mostly for deleting the connection from an Element to an InputEnabled Element (since actually wiring them together is done in a different view) - So it would make sense to have a "ManageConnnections" method in IInputEnabled. But since I want this to be consistent across all IInputEnabled objects, the only way I can think of accomplishing this is to have an object inherit from IInputEnabled AND a base class which implements this; which I'd prefer to avoid and keep it all in interfaces for consistency.The alternative as far as I can see, is to create a ConnectionModifier object that can be viewed as a type of controller for IInputEnabled elements, and invoke it to visit the element and modify the connection hashtable - which would require making the connection table a public component of the interface. So the question is, what are the caveats to either design - and are their alternatives that I haven't considered?   
interface IElement {  void configure();  bool hasInput();  bool hasOutput();  List<IElement> getInputs(); // returns empty list if IElement has no inputs  List<IElement> getOutputs();  void connectInput(IElement e);  void connectOutput(IElement e);  void emit(); // sends stuff to zero, one or more outputs, depends on logic  void receive(IElement, data?); // called by sender's emit()  // emit() could also poll inputs, depends on design}Not everything has to be an object or iInterface.To be extra fancy, make a special concrete List<IElement> which has the convenient connect method, but it's not really needed.Think of it this way, with this design, there is only a single interface/file to maintain. The more interfaces/classes there are, the more unit tests, files, implementation there needs to be.   ;Quote:Original post by Antheusinterface IElement {  void configure();  bool hasInput();  bool hasOutput();  List<IElement> getInputs(); // returns empty list if IElement has no inputs  List<IElement> getOutputs();  void connectInput(IElement e);  void connectOutput(IElement e);  void emit(); // sends stuff to zero, one or more outputs, depends on logic  void receive(IElement, data?); // called by sender's emit()  // emit() could also poll inputs, depends on design}Not everything has to be an object or iInterface.To be extra fancy, make a special concrete List<IElement> which has the convenient connect method, but it's not really needed.Think of it this way, with this design, there is only a single interface/file to maintain. The more interfaces/classes there are, the more unit tests, files, implementation there needs to be.Awesome. I still struggle with over complicating things and this design makes bucketloads of sense. Thanks for helping me see the forest through all the trees.   ;  I totally agree on the simplification. That said, you are able to create methods on interfaces via extension methods:public interface IFoo {}public static class ExtendFoo{    public static void DoStuff(this IFoo arg){   // do stuff.    }}// elsewhereIFoo someFoo; //...someFoo.DoStuff(); It's not exactly common knowledge, but occasionally useful.   ;  So my implementation differed a bit. One thing that I think I didn't make clear in my original post is that any Element can have any number of named inputs but only one element can plug into each input - so it's not an aggregate of Elements, it's direct associations of one element to one (named) input. The view needs to query the Element to find out what inputs to draw in the interface. So I went with an IElement to define the interface to the element, an ElementBase, and then derived subsequent elements from that.interface IElement{    bool hasInputs{ get; }    bool hasOutput{ get; }    List<string> GetInputNames();   void Connect(IElement InputElement, string input);    void Disconnect(string input);    void DisconnectAll();   double Emit();    void Tick();} Then in ElementBase I define:class ElementBase : IElement{    public virtual bool hasInputs{ get{ return false; } }    public virtual bool hasOutput{ get{ return false; } }    public virtual double Emit(){ return 0;}    public virtual void Tick() {}    protected List<string> Inputs;    protected Hashtable Connections = new Hashtable();    public List<String> GetInputNames() { return Inputs; }    public void DisconnectAll() { Connections.Clear(); }    public void Disconnect(string input) { Connections.Remove(input); }    public void Connect(IElement InputElement, string input) { Connections[input] = InputElement; }} Then, as an example, I create VCO as an ElementBaseclass VCO : ElementBase{   override public bool hasInputs{ get{ return true;} }   override public bool hasOutput{ get{ return true;} } double CurrentValue = 0;   public VCO()   { Inputs.Add("frequency"); Inputs.Add("amplitude"); Inputs.Add("phase");   }   //called every 1/44100 seconds   public override void Tick()   {doubl FreqMod = 0;if(Connections.Contains("frequency"){  IElement Freq = (IElement)Connections[frequency];  FreqMod = Freq.Emit();  }//... etc. modulate Frequency/Amplitude/Phase based on inputs   }   public override double Emit()   { return CurrentValue;   }}This way the interface can query an Element to determine what inputs it has to draw and what to name them. Originally I wanted to avoid having a base class because of C#'s limitation on multiple inheritance; but after some thought figured the circumstances that would require me to multiple inherit are pretty much solvable in better ways*.What I'm wondering now is: A) is there any point to keeping the IElement interface? and B) I think the Hashtable solves my issue fairly elegantly, but is there another way of going about this that makes more sense? I'm concerned with performance, but also wanting to keep the code readable. I can add some simple logic so the Hashtable is only queried if the connections have changed.* edit: by multiple inherit what I really meant was, the circumstances where an element deriving from ElementBase could conceivably want to derive from something else...well, I can't really imagine a scenario where I'd need to do this.;  Don't use HashTable. Dictionary<K,V> has the same sort of performance characteristics but provides proper type safety.I don't know a lot about DSP behaviors but this still seems awkward.   ;Quote:Original post by TelastynDon't use HashTable. Dictionary<K,V> has the same sort of performance characteristics but provides proper type safety.I don't know a lot about DSP behaviors but this still seems awkward.It's not quite full DSP, more like, building DSP out of tiny parts that all have specific inputs (like frequency/phase/amp for a sin osc, or time/feedback for delay, gain/shape for a wave shaper) and using these to build up processors and synths. I suppose a better way might be to create an InputType class that defines its string name, and put those in a list. Then I could index them internally with an indexed lookup to the list, rather than a dictionary lookup.As far as how the main loop goes, it's basicallyfor(int i=0; i<NumSamples_ToBuffer; ++i){    foreach(Element Element in Elements){ Element.Tick(); }    buffer = OutputElement.Emit();}