locked
Best practice with method signatures? RRS feed

  • Question

  • The second method below was created while adding new functionality.  This made me realize that the original method with just one parameter can be removed, if the new one is used in its place.  

    Using the new one where the old one is would require some modifications to the implementations.  An empty string would have to be passed for fundName in the locations the fundName isn't used.  Alternately, making the fundName parameter nullable and passing a null would be another way to deal with the second fundName parameter, if it's not used in a location.

    I'm wondering if it's better to have both methods or just the one with two parameters.  I thought there may be a best practice recommendation for this.  The down side of just having the new one with two parameters and removing the old one is that some implementations would have to pass a null or empty string for fundName.  This would require extra work.  There are only a couple places it would have to be changed, so it wouldn't be a lot of work.

    It's easier to add a new method with a different signature(two parameters)when new functionality is added.  This would eliminate the need to redo existing implementations, reduce the potential for new bugs and not increase the amount of testing needed.

    I'm wondering if there's a best practice or recommendation when it comes to this.  What I mean is just: adding a new method with a new signature and leaving the existing with one parameter versus removing the existing method and modifying the current implementations by passing nulls or empty strings for the new parameter.

    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship);                                            
    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship, string fundName);             

    Wednesday, June 29, 2016 3:17 PM

Answers

  • I would say that if you have a method, where sometimes you want to call it with two parameter, but sometimes the second parameter is irrelevant and you can pass null/empty string/some other default, then you have two choices.

    One, slightly 'older' way would be to have two methods like you already have, but where the first calls the second and passes in the default:

    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship)
    {
      return ConfigureOnsiteCompleteMessage(managerRelationship, null);
    } 

    Or, the better way would be to use optional parameters. This way you don't need the first method. Simply use the second method with two parameters and make the second parameter optional:

    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship, string fundName = null);  

    Have a look at optional arguments in this page (about half-way down).



    • Proposed as answer by Christopher84 Wednesday, June 29, 2016 4:16 PM
    • Edited by RJP1973 Wednesday, June 29, 2016 4:21 PM Corrected a copy/paste error
    • Marked as answer by new to sql server Wednesday, June 29, 2016 7:06 PM
    Wednesday, June 29, 2016 3:34 PM

All replies

  • I would say that if you have a method, where sometimes you want to call it with two parameter, but sometimes the second parameter is irrelevant and you can pass null/empty string/some other default, then you have two choices.

    One, slightly 'older' way would be to have two methods like you already have, but where the first calls the second and passes in the default:

    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship)
    {
      return ConfigureOnsiteCompleteMessage(managerRelationship, null);
    } 

    Or, the better way would be to use optional parameters. This way you don't need the first method. Simply use the second method with two parameters and make the second parameter optional:

    string ConfigureOnsiteCompleteMessage(OWF_ManagerRelationshipViewModel managerRelationship, string fundName = null);  

    Have a look at optional arguments in this page (about half-way down).



    • Proposed as answer by Christopher84 Wednesday, June 29, 2016 4:16 PM
    • Edited by RJP1973 Wednesday, June 29, 2016 4:21 PM Corrected a copy/paste error
    • Marked as answer by new to sql server Wednesday, June 29, 2016 7:06 PM
    Wednesday, June 29, 2016 3:34 PM
  • Hi,

    I guess if you use the second method you didn't need have the first one. The only difference is that your in  second method you have to pass two parameter I think which is best practice. In this way you could use it to the other part of your program.

    Also the second method is more clear to understand that the this method accept a string type value. If you don't define in this way then you have to manually navigate to the function to see what type of parameter you can pass there. Hope this helps you.

    Thanks,

    Sabah Shariq

    Wednesday, June 29, 2016 3:39 PM
  • The ideal case is to have the minimum amount of overloads. Or at least the minimum amount of real code implementations.
    One function calling a different overload is a time honored tradition, even in the .NET Framework clases itself. Constructor chaning is so common, there is a special Syntax for it (optional parameters are a somewhat new thing, I think C#4 or 5 implemented them earliest).

    My Math Teacher used to say: "Mathematicians are lazy writers." The reason is simple: The more you write, the more you can make mistakes.
    This rule applies to programmers too. The less code you have, the less redundancy your code has, the less you can do wrong.

    Never bother about potential speed bumbs for having one overload call the other or using default parameters. They are neglibible for the gain in usability and maintainability.
    If you need to kind of speed optimisations where 1 call or 5 calls mater, a High Level programming language with Garbage Collection memory approach would be a dead end anyway.

    Also note these two soruce regarding speed optimisation:

    Which is faster? | Fabulous Adventures In Coding

    http://xkcd.com/1691/


    Wednesday, June 29, 2016 4:24 PM
  • I forgot about optional parameters.  They make a lot of sense in this situation.  

    This approach will add the new argument to accommodate the new functionality while not requiring existing implementations be updated.   Not updating or changing the existing functionality by using optional parameters will also not increase the amount of potential changes or testing required.

    Christopher84: Thanks for the links. 

    Wednesday, June 29, 2016 7:05 PM