• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

C# interface method - generic vs object parameter

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    C# interface method - generic vs object parameter

    If I want to create a C# interface with a general "DoProcessing" method that then calls other methods depending on the argument(s) passed in, which is better:

    1) Generics, for example:

    interface IMyInterface<T>
    {
    void DoProcessing(T myParam1, string myParam2)
    {
    // Maybe have a switch statement here to call various methods depending on what value myParam2 has.
    }
    }

    2) Object parameter, for example:

    interface IMyInterface
    {
    void DoProcessing(object myParam1, string myParam2);
    {
    // Maybe have a switch statement here to call various methods depending on what value myParam2 has.
    }
    }


    For both of the above, the second parameter (myParam2) might be a method name or enum for some kind of state (e.g. "busy", "idle", "blocked").

    #2
    Originally posted by jamsandwich View Post
    If I want to create a C# interface with a general "DoProcessing" method that then calls other methods depending on the argument(s) passed in, which is better:

    1) Generics, for example:

    interface IMyInterface<T>
    {
    void DoProcessing(T myParam1, string myParam2)
    {
    // Maybe have a switch statement here to call various methods depending on what value myParam2 has.
    }
    }

    2) Object parameter, for example:

    interface IMyInterface
    {
    void DoProcessing(object myParam1, string myParam2);
    {
    // Maybe have a switch statement here to call various methods depending on what value myParam2 has.
    }
    }

    For both of the above, the second parameter (myParam2) might be a method name or enum for some kind of state (e.g. "busy", "idle", "blocked").

    Personally I would avoid the switch statement and consider alternatives first you could use Dependency Injection to inject the behaviour of the method when the object is instantiated or pass the behaviour in using Func. But option 2 seems cleaner, instead of an object I would declare the method with an interface in param.


    .net - Pass Method as Parameter using C# - Stack Overflow
    Make Mercia Great Again!

    Comment


      #3
      Originally posted by BlueSharp View Post
      Personally I would avoid the switch statement and consider alternatives first you could use Dependency Injection to inject the behaviour of the method when the object is instantiated or pass the behaviour in using Func. But option 2 seems cleaner, instead of an object I would declare the method with an interface in param.


      .net - Pass Method as Parameter using C# - Stack Overflow
      Thanks for the reply.

      I just thought of another idea...

      How about using different classes to represent the different actions that the switch statement might have executed. I think that's what is known as "Replace Conditional With Polymorphism".

      Replace Conditional with Polymorphism

      Is that what you meant by Dependency Injection? Only problem I see is that it might lead to a lot of small classes. Maybe I could put them all in one file to save bloating out the solution?

      Comment


        #4
        Originally posted by jamsandwich View Post
        Thanks for the reply.

        I just thought of another idea...

        How about using different classes to represent the different actions that the switch statement might have executed. I think that's what is known as "Replace Conditional With Polymorphism".

        Replace Conditional with Polymorphism

        Is that what you meant by Dependency Injection? Only problem I see is that it might lead to a lot of small classes. Maybe I could put them all in one file to save bloating out the solution?
        Yes that is the same concept. Lots of small files make implementing the same interface sticks to SOLID principles. If you start with the unit testing for the method and class you will quickly know if this is over kill or required due to the complexity of the case statement.
        Make Mercia Great Again!

        Comment


          #5
          Sounds like you are implementing a virtual method table.

          Virtual method table - Wikipedia

          So to do it in C# you would have e.g. a dictionary<string, action> and dispatch the call thusly: dict[param]()

          To make it testable, DI friendly you would encapsulate this logic in a class / interface with e.g. registerhandler(string, action) and execute(string) methods etc.

          Comment

          Working...
          X