Optional Parameters and Method Overloads

The ability to declare optional parameters is another feature that will be introduced in C# 4.0. A natural complement to method overloads, it generally helps code to be more concise. Until now, method overloads have been used for the awkward responsibility of creating default values for what otherwise would be much better expressed as optional parameters. Many overloads have been created for which the sole responsibility is to call another overload with some default values for some parameters. 

public CreditScore CheckCredit() {
  return CheckCredit(false, true);
}
public CreditScore CheckCredit(bool useHistoricalData) {
  return CheckCredit(useHistoricalData, true);
}
public CreditScore CheckCredit(
  bool useHistoricalData, bool useStrongHeuristics) {
  // do the heavy-lifting ...
}

For this style of method, optional parameters let you create just one method, with default values set on its signature. 

public CreditScore CheckCredit(
  bool useHistoricalData = false, 
  bool useStrongHeuristics = true) {
  // ...
}

The key to make a parameter optional is to provide it with a default value. This code is less verbose and easier to maintain than the one with the overloads. The caller can omit any optional parameters and their default value will be what the method ultimately receives. This makes a lot of sense coupled with named parameters. 

var creditScore = customer.CheckCredit(
  useStrongHeuristics: false);

Method overloads still have their place though. Normally when different versions of a method don't share code or when one must do some processing before or after calling another method, you'll still want to overload them. A good rule of thumb is if two methods have mutually exclusive sub-sets of parameters, they should be modeled as overloads.

public void SendSurvey(IList<Customer> customers, int surveyKey) { 
  // will loop and call the other one
}

public void SendSurvey(Customer customer, int surveyKey) { 
  ... 
}

Comments

Post a Comment

Popular posts from this blog

The Acyclic Visitor Pattern

Knock knock The visitor design pattern is a way to add new operations to a hierarchy of classes without having to change the hierarchy itself. For example, with a simple hierarchy of fruits, you can have an IFruitVisitor interface that operates on the different classes in the hierarchy (in C#): interface IFruitVisitor { void Visit(Apple apple); void Visit(Grape grape); } The hierarchy classes then accept the visitor and fulfil the double-dispatching necessary to call the right Visit method: abstract class Fruit { public abstract void Accept(IFruitVisitor visitor); } class Apple : Fruit { public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } class Grape : Fruit { public int NumberOfGrapes { get; set; } public override void Accept(IFruitVisitor visitor) { visitor.Visit(this); } } Note how each Accept method looks the same but is actually dispatching to a different method in the visitor ( Visit(Apple) and Visit(Grape) ).
Read more

C# Mixins With State

With the C# quasi-mixin pattern , one of the biggest limitations is that the mixins can't introduce state to a class. An alternative was for the mixin interface to require the composing classes to implement a property that the mixin would use as its own, as demonstrated in this example . In the .NET Framework 4.0, the ConditionalWeakTable<TKey, TValue> class can be used to associate arbitrary state to any instance. It's thread safe and it keeps a dictionary of weak references from the target instance to its associated state. If a target instance has no references outside the conditional weak table, then it can be reclaimed by the garbage collector. When that happens, its entry in the table is removed. This makes it possible for a mixin-like class to maintain state for the instances it extends. Let's look at a mixin for a message container: public enum MessageType { Error, Warning, Info } public class Message { public readonly MessageType Type;
Read more

Some OO Design

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology." - Craig Larman I've recently found the following interview question on stackoverflow : Basic sales tax is applicable at a rate of 10% on all goods, except books, food, and medical products that are exempt. Import duty is an additional sales tax applicable on all imported goods at a rate of 5%, with no exemptions. When I purchase items I receive a receipt which lists the name of all the items and their price (including tax), finishing with the total cost of the items, and the total amounts of sales taxes paid. The rounding rules for sales tax are that for a tax rate of n%, a shelf price of p contains (np/100 rounded up to the nearest 0.05) amount of sales tax. This is a very familiar example that can be used as a really good gauge of various software development skills. There are many different ways to solve this problem.
Read more