Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

When to interface

Options
  • 09-11-2009 10:23am
    #1
    Registered Users Posts: 15


    I'm posing this question to you all to make sure that I am right in developing an interface.

    To aid my understanding in C#, I decided to create a calculator application, where the back end was a class calculator that took care of the functionality and to develop a front end with console and GUI versions. I created functionality Add, Subtract, Multiply, Divide as core function inside calculator but I also had Display, Clear, Equals and Off as virtual functions.

    I started on the gui version and to my surprise (though it should not have surprised me) the calculator gui form had already inherited from form and because c# does not allow multiple inheritance, I'm thinking that I should create an interface with the signatures Display, Clear, Equals and Off.

    Would any of ye agree with this? I mean when do you decide to use an interface?


Comments

  • Registered Users Posts: 981 ✭✭✭fasty


    Don't make your form inherit an interface just to implement calculator functionality. What you did in the first instance, by creating a calculator class is right.

    What you could do is put events in your calculator class so that when you press Equals on the UI, the Calculator class fires an event. This way your Calculator class can be hooked into any type of app and isn't coupled to a text or graphical interface or indeed any interface at all!

    Here's an example below which matches how MS would like you to do it.
    public delegate void EqualEventHandler(object sender, EventArgs e);
    
    class Calculator
    {
        public event EqualEventHandler EqualsEvent;
        
        public void Equals()
        {
            // Do your actual work here!
            // Then call OnEquals.
            // You could make a custom EventArgs base class here to include extra info if you liked.
            OnEquals(EventArgs.Empty);
        }
    
        protected virtual void OnEquals(EventArgs e)
        {
            if (EqualsEvent != null)
                EqualsEvent(this, e);
        }
    }
    
    class SomeCalcView
    {
        Calculator cal;
    
        SomeCalcView()
        {
            cal = new Calculator();
            cal.EqualsEvent += new EqualEventHandler(cal_EqualsEvent); // Register event
        }
    
        void cal_EqualsEvent(object sender, EventArgs e)
        {
            // Tell your UI to update the display!!!
        }
    }
    

    As for when to use an interface... Use it when you want to define how other objects interact with something, but where the actual implementation could change. You could also use an interface to force a common set of functions on a number of similar classes much like all the collection classes in .Net implement the IEnumerable interface.


  • Registered Users Posts: 15 eatchicken


    Hey Fasty. Thanks for your input. Indeed this is a good solution and I happen to finally know what good deligates are.

    I used to know about pointer functions in c++ before and I never knew just what good they were. Ahhh but now I see :D


Advertisement