Warning: Use of undefined constant wp_cumulus_widget - assumed 'wp_cumulus_widget' (this will throw an Error in a future version of PHP) in /var/www/kjeldby.dk/blog.kjeldby.dk/wp-content/plugins/wp-cumulus/wp-cumulus.php on line 375
Method signatures – C# and stuff
Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /var/www/kjeldby.dk/blog.kjeldby.dk/wp-content/plugins/ultimate_ga_1.6.0/ultimate_ga_1.6.0.php on line 524
Skip to content

Categories:

Method signatures


Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /var/www/kjeldby.dk/blog.kjeldby.dk/wp-content/plugins/ultimate_ga_1.6.0/ultimate_ga_1.6.0.php on line 524

With a few simple tricks, you can avoid those annoying changes in the method signatures in your application.

Method signatures are important point of integration in your application, and hence changes in your method signatures can be both annoying and error prone, and even break applications that consumes your code. So method signatures should be as stable and decoupled from the method implementation as possible. This can be done by e.g. defining interfaces, but I’ve learned that a few simple tricks can often make a huge difference.

A methods signature is its fingerprint: It’s name, parameters and return type. I am working on an application, where I search out segments of costumers in a database based on different segmentation options, e.g. zipcode, gender and last name. The method is called SearchCostumers. The gender is a enumerations called Gender, whereas the the zipcode and last name are strings. I return a generic collection of costumers from the method. So my methods signature is basically:

public List SearchCostumer(string zipcode, Gender gender, string lastName)

Now the name of this method is not likely to change, but the parameters are. Someday I will need to implement new segmention options like age, number of orders and so on. So oe way to avoid signature changes is by implementing a CostumerQuery object. The CustomerQuery is a simple container including the parameters, CostumerQuery.ZipCode, CustomerQuery.Gender and CustomerQuery.LastName. So before I do my search, I’ll simply populate an instance of my query object, and pass it to the search:

public List SearchCostumer(CostumerQuery costumerQuery)

The benefit is, that when I need to add new search parameters, I’ll simply add them to the query object, and specify som default value. This will prevent code from breaking, even code written for the old method.

Another way to decouple the method is by returning my collection of costumers as a IList. The IList is a generic interface available from .NET 2.0, implemented by the List object. It represents a collection of objects, that can be individually accessed by index, and supports the operations that I need to perform on the returned costumers. So instead of binding my application to Microsoft specific implementation of the IList interface, I return my list as a interface instead. Note that the actual collection returned is still a List – it is simply returned as the less specific interface IList.

public IList SearchCostumer(CostumerQuery costumerQuery)

Now, I’ll admit that not everybody will choose to return interfaces instead of the actual type, but the option exists. And to be hornest – In case mentioned above, it was not plausible that the returned type would ever change, so mainly due to lazyness I just returned the darn List.

Posted in C#.

Tagged with , , , .




Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /var/www/kjeldby.dk/blog.kjeldby.dk/wp-content/plugins/ultimate_ga_1.6.0/ultimate_ga_1.6.0.php on line 524

Warning: Use of undefined constant user_level - assumed 'user_level' (this will throw an Error in a future version of PHP) in /var/www/kjeldby.dk/blog.kjeldby.dk/wp-content/plugins/ultimate_ga_1.6.0/ultimate_ga_1.6.0.php on line 524