Michał Kajzer - Personal web page

Method parameters – overview

Syntax of C# enables multitude of ways how to pass parameters into a method. The most basic way is to provide a parameter type and name. This will enforce that whenever this method is called this parameter must be supplied and the method will produce a result based on that. However this is not the only way, and surprisingly (at least for beginners) C# offers quite wide range of customisation of method signatures.

Optional parameter
A parameter can be optional, and in case it is not passed in a call its default value will be used.

void DefaultValueParam(string param, string defaultParam="default", string defaultParamTwo="default two")

1	void DefaultValueParam(string param, string defaultParam="default", string defaultParamTwo="default two")

In this case there are two things to be aware of:
i) optional parameters must be at the end, any other parameter cannot be after optional (a compiler will not allow that);
ii) if a method with more than one optional parameter is called the order of them matters, so in the example above if first optional parameter is to be provided, the second is to be omitted the you simply call the method without the last one which will take its default value:

DefaultValueParam("my param", "non-default");

1	DefaultValueParam("my param", "non-default");

However if one wish to provide only second parameter and use default value of the first optional parameter one must pass it as named parameter:

DefaultValueParam("my param", defaultParamTwo: "ddd");

1	DefaultValueParam("my param", defaultParamTwo: "ddd");

Reference parameters
In .NET there is distinction between value types and reference types [more]. So generally objects are passed by reference (as they are reference types), primitive types are passed by value (as they are value types, as well as structs). This means, in simple words, that changes a method do to an object will be visible outside. That doesn’t happen to a value type. The ref keyword allows us to declare in method’s signature that a parameter is to be passed by reference (even if it’s a value type).

void RefParam(ref int number)
{
    number++;
}

void RefParam(ref int number)

{

number++;

}

Let’s consider the above code: if the RefParam() is to be called it will expect a reference to an integer variable which will be modified inside the method and saved to a reference. It will not accept hard-coded value. Note that the ref keyword needs to be present in both: method’s declaration and method’s call.

int n = 9;
RefParam(ref 9); //this will produce a compiler error
RefParam(ref n);
Console.WriteLine(n) //this will output "10"

int n = 9;

RefParam(ref 9); //this will produce a compiler error

RefParam(ref n);

Console.WriteLine(n) //this will output "10"

The above code will output value of n variable which is now increased by the RefParam() method.

There are two more ways to pass a parameter by reference: the in and out keywords. The former enforces that the parameter is not modified inside a method, the latter enforces that the parameter is set inside the method.

static int InMethod(in int val, int regularInt)
{
    val++; //this will produce a compiler error 
    return val + regularInt;
}

static int InMethod(in int val, int regularInt)

{

val++; //this will produce a compiler error

return val + regularInt;

}

So as you can see a compiler will not allow any code that would potentially change value of reference parameter with in keyword. The advantage is that since it is passed by reference it will not be boxed (performance advantage) and you can clearly state at design that this parameter is not to be modified but read-only. Note that the in keyword is available in C# 7.2.

void OutMethod(out int val)
{
    val = 99; //a statement setting value of out parameter is required
}

void OutMethod(out int val)

{

val = 99; //a statement setting value of out parameter is required

}

In a method which one parameter is declared as out there must be a statement that would set its value. If not a compiler would generate an error. In this case (similarly as with the in keyowrd) we have this explicit declaration that in the method we need to modify value of a parameter. Another advantage is that we can new-up a variable when a method is called:

OutMethod(out x); //variable x must be already declared
OutMethod(out int y); //inline declaration of new variable

1 2	OutMethod(out x); //variable x must be already declared OutMethod(out int y); //inline declaration of new variable

This may be used as a way return more that one value by a method [more].

Multiple parameters of the same type
In case we want to pass unknown number of parameters of the same type we can use the params keyword.

ParamsMethod("joe", "john", "joseph");
ParamsMethod("mike", "michael");

1 2	ParamsMethod("joe", "john", "joseph"); ParamsMethod("mike", "michael");

If we want the above to work we could declare an overloaded method, however using the params keyword makes it way easier.

static void ParamsMethod(params string[] names)
{
    foreach (string name in names)
    {
        Console.WriteLine(name);
    }
}

static void ParamsMethod(params string[] names)

{

foreach (string name in names)

{

Console.WriteLine(name);

}

However, in this case we need to remember that type of this parameter must be an array (one dimensional, compiler won’t allow anything else) and it must be declared as the last parameter in a method’s signature.

That is short overview how flexible declaring a method can be. I encourage to experiment with it to get comfortable with all the possibilities C# language offers in this matter.

I’m back and Git – rookie’s thoughts

Hello there!
It’s certainly been a while since my last post! It was more or less 6 months ago which is a long time but I wasn’t idle, oh no! If you briefly scan all my posts you’ll notice that my field of interests was Windows apps, mostly WPF technology and MVVM pattern. However this has recently changed – I’ve started ASP.NET app! The project is a web app for acquainted company which purpose is to organise and keep track of service jobs they provide to their client. It is not an open project so I can’t share the code at the moment. Let me say only that it is an MVC app using what comes by default with an MVC template in Visual Studio (Entity Framework, Identity, bootstrap, jQuery etc.) so as you can see a lot of new things!

Here you go a screenshot of the early version of the current app (first version is up and running, but it is very very basic so they have anything to start with). Let me stop here about this project and let’s move on to the next thing which is:

Git – my first thoughts

So, I’ve already been using GitHub (here’s my account) but recently I did a quick course on Git (on LinkedIn Learning [link]) so I thought why not to try it on my own. So I downloaded packages, created separate partition on my hard drive and installed it and started using it. As I’m a beginner I use only some basic commands that you definitely know:

git status – shows current changes and what’s been staged
git add . – adds all changes to commit stage, the dot indicates that all files must be added, you could replace it by a specific file name
git commit -m”<message>” – commits staged changes to a repository with a message, I generally try to always commit with a message
git commit -am”<message>” – adds to stage all changes (except new files) and commits them to a repository
git log –x – prints out a log of a commit where x is an ordinal number of a commit (1 – is the newest)
git push – pushes (uploads) all commits to a remote repository

And that’s more or less it. That’s enough for me to start.
Now, a word about remote repository. You can use GitHub to host your remote repositories, they offer unlimited number but in a free plan they can only be public repositories (it’s easy to find how to set it all up on their help pages). If you’re looking for a private repo you can simply use your local drive (once you have a directory set up simply run git bash, navigate to this directory and execute git init, or start your project in Visual Studio and tick the Create new Git repository option). However if you still need the remote repository to push your commits (for instance to share the source code with others working with you on a project, or for backup) what you can do is to use Visual Studio Team Services . They offer private repositories. To set a remote address for your repo in VSTS you need to:
a) once you are registered and logged to VSTS you need to create new project with version control set to Git
b) go to https://xxx.visualstudio.com/_projects where xxx is your alias and click on your project’s name, this will bring you to project’s homepage
c) unfold second category as below
d) execute the above commands in your git bash (of course your URL will differ)

It’s all set! This basically links your local repo with a remote repo at VSTS. In the above command ‘origin’ is a name for the remote repo. If your case is that you use only one remote repository you don’t need to specify it when executing the push command in future.
So, that’s about it what I wanted to say about my first steps with git. Maybe as a side note I’d add that help files that come together with git installation are really really helpful so I encourage to look for solution there in case you encounter any problem.

One-bytes #3: Methods returning multiple values or the Tuples

*** #3.1 How to return multiple values from method***
Quick one today – how to write a method that returns more than one value. There are two ways: i) use out keyword, ii) use generic class Tuple. In the first approach we return first value as we usually do, the second value will be passed as parameter with out keyword. Take a look at example method:

public string OutMethod(int param, out string returned)
{
    returned = String.Format("This is set by method: {0}", param);
    return String.Format("This is returned value: {0}", param);
}

public string OutMethod(int param, out string returned)

{

returned = String.Format("This is set by method: {0}", param);

return String.Format("This is returned value: {0}", param);

}

Now if we want to make use of this method we either need to have a variable pre-declared and pass it into the method or declare it inline in the place of invocation:

//out method - pre-declared
string value2P;
string value1P = OutMethod(9, out value2P);
Console.WriteLine(value1P);
Console.WriteLine(value2P);

//out method - inline declaration
string value1 = OutMethod(9, out string value2);
Console.WriteLine(value1);
Console.WriteLine(value2);

//out method - pre-declared

string value2P;

string value1P = OutMethod(9, out value2P);

Console.WriteLine(value1P);

Console.WriteLine(value2P);

//out method - inline declaration

string value1 = OutMethod(9, out string value2);

Console.WriteLine(value1);

Console.WriteLine(value2);

Nice and simple, right? It the second approach we make use of Tuple generic class. It works with up to 8 generic parameters meaning that we can return 8 values (but nobody says that one of the returned values is another tuple, so in practice we can go for how many values as we want). Here’s an example:

public Tuple<string, string> TupleMethod(int param)
{
    string value1 = String.Format("This is set by method: {0}", param);
    string value2 = String.Format("This is returned value: {0}", param);
    return new Tuple<string, string>(value1, value2);
}

public Tuple<string, string> TupleMethod(int param)

{

string value1 = String.Format("This is set by method: {0}", param);

string value2 = String.Format("This is returned value: {0}", param);

return new Tuple<string, string>(value1, value2);

}

So this method in fact returns one value of type Tuple. So how to access the values we really want?

//tuple method
var result = TupleMethod(9);
string valueA = result.Item1;
string valueB = result.Item2;
Console.WriteLine(valueA);
Console.WriteLine(valueB);

//tuple method

var result = TupleMethod(9);

string valueA = result.Item1;

string valueB = result.Item2;

Console.WriteLine(valueA);

Console.WriteLine(valueB);

Again, nice and simple. Which way is better? I guess the one you prefer 🙂

Tuple Class on msdn.com

One-bytes #2: Selection in WPF, OnPropertyChanged parameters

*** #2.1 Item selection in WPF selector-enabled items control***
In WPF we can use multiple types of controls to display collections of items which allow user to select one or multiple items from the collection. In this post I’m going to discuss what single selection possibilities they offer.
Let’s start with inheritance hierarchy – controls that allow such selection inherit from System.Windows.Controls.Primitives.Selector. If we take a look at what properties they have we find four that may be involved in selection process:

SelectedIndex – Gets or sets the index of the first item in the current selection or returns negative one (-1) if the selection is empty.

SelectedItem – Gets or sets the first item in the current selection or returns null if the selection is empty

SelectedValue – Gets or sets the value of the SelectedItem, obtained by using SelectedValuePath.

SelectedValuePath – Gets or sets the path that is used to get the SelectedValue from the SelectedItem.
source: msdn.microsoft.com

So, there are three ways get the selected item: i) its integer index in the collection, ii) the item itself, iii) one desired value from the item.
I have prepared a quick demo to show that. The app displays a ListBox of custom class objects and once an item is selected displays all three ways to present the selection. Let’s take a look into the code, starting with the class of objects that our list will contain:

public class Item
{
    public string Name { get; set; }
    public int Value { get; set; }

    public Item(string _name, int _value)
    {
        Name = _name;
        Value = _value;
    }
}

public class Item

{

public string Name { get; set; }

public int Value { get; set; }

public Item(string _name, int _value)

{

Name = _name;

Value = _value;

}

The list will be generated and stored in view model. The view model will also have three public properties: i) ItemSelectedIndex of type integer bound to SelectedIndex property of our ListBox, ii) ItemSelectedItem of type Item bound to SelectedItem, iii) ItemSelectedValue of type string bound to SelectedValue. Let’s take a look at complete ViewModel class:

public class ViewModel : INotifyPropertyChanged
{
    private List<Item> items;
    public IReadOnlyList<Item> Items
    {
        get { return items.AsReadOnly(); }
    }

    public ViewModel()
    {
        items = new List<Item>();
        for (int i = 1; i <= 10; i++)
        {
            items.Add(new Item(String.Format("Item number {0}", i.ToString()), i * 3));
        }
    }

    private int itemSeletctedIndex;
    public int ItemSelectedIndex
    {
        get { return itemSeletctedIndex; }
        set
        {
            itemSeletctedIndex = value;
            OnPropertyChanged(nameof(ItemSelectedIndex));
        }
    }

    private Item itemSelectedItem;
    public Item ItemSelectedItem
    {
        get { return itemSelectedItem; }
        set
        {
            itemSelectedItem = value;
            OnPropertyChanged(nameof(ItemSelectedItem));
        }
    }

    private string itemSelectedValue;
    public string ItemSelectedValue
    {
        get { return itemSelectedValue; }
        set
        {
            itemSelectedValue = value;
            OnPropertyChanged(nameof(ItemSelectedValue));
        }
    }

    #region INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;

    private void OnPropertyChanged(params string[] propertiesChanged)
    {
        if (PropertyChanged != null)
        {
            foreach (string property in propertiesChanged)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(property));
            }
        }
    }
    #endregion
}

public class ViewModel : INotifyPropertyChanged

{

private List<Item> items;

public IReadOnlyList<Item> Items

{

get { return items.AsReadOnly(); }

}

public ViewModel()

{

items = new List<Item>();

for (int i = 1; i <= 10; i++)

{

items.Add(new Item(String.Format("Item number {0}", i.ToString()), i * 3));

}

private int itemSeletctedIndex;

public int ItemSelectedIndex

{

get { return itemSeletctedIndex; }

set

{

itemSeletctedIndex = value;

OnPropertyChanged(nameof(ItemSelectedIndex));

}

private Item itemSelectedItem;

public Item ItemSelectedItem

{

get { return itemSelectedItem; }

set

{

itemSelectedItem = value;

OnPropertyChanged(nameof(ItemSelectedItem));

}

private string itemSelectedValue;

public string ItemSelectedValue

{

get { return itemSelectedValue; }

set

{

itemSelectedValue = value;

OnPropertyChanged(nameof(ItemSelectedValue));

}

#region INotifyPropertyChanged

public event PropertyChangedEventHandler PropertyChanged;

private void OnPropertyChanged(params string[] propertiesChanged)

{

if (PropertyChanged != null)

{

foreach (string property in propertiesChanged)

{

PropertyChanged(this, new PropertyChangedEventArgs(property));

}

#endregion

}

And now the most important part – the view. As mentioned above as a container for collection we will use ListBox and bound properties as it was described when discussing the view model class. The only thing that’s left is setting correct value to SelectedValuePath property. In this case we want to use Name property of our item class so we need to set SelectedValuePath to “Name”. Here’s how to set the ListBox up:

<ListBox ItemsSource="{Binding Items}" Grid.Column="0" SelectedIndex="{Binding ItemSelectedIndex}" SelectedItem="{Binding ItemSelectedItem}" SelectedValue="{Binding ItemSelectedValue}" SelectedValuePath="Name">
  <ListBox.ItemTemplate>
    <DataTemplate>
      <TextBlock>
        <TextBlock.Text>
          <MultiBinding StringFormat="{}{0} [{1}]">
            <Binding Path="Name"/>
            <Binding Path="Value"/>
          </MultiBinding>
        </TextBlock.Text>
      </TextBlock>
    </DataTemplate>
  </ListBox.ItemTemplate>
</ListBox>

<ListBox.ItemTemplate>

<TextBlock.Text>

</MultiBinding>

</TextBlock.Text>

</TextBlock>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

Now, to use the selected index, item or value which are bound to corresponding properties in view model we need to add some controls and again bound them to view model properties:

<StackPanel Grid.Column="1" Margin="5,0">
  <TextBlock Text="{Binding ItemSelectedIndex, Mode=OneWay}"/>
  <TextBlock Text="{Binding ItemSelectedValue, Mode=OneWay}"/>
  <TextBlock Text="{Binding ItemSelectedItem, Mode=OneWay}"/>
</StackPanel>

</StackPanel>

And that’s it. To sum things up – there are three ways to access selected item in a selector control in WPF: by its index, by the item itself or by one particular value in the item.

*** #2.2 Passing property name to OnPropertyChanged()***
Second thing I want to mention today is a hint how to make invoking OnPropertyChanged() method in a property setter a bit more controlled when not using any MVVM framework.
ViewModels usually implement INotifyPropertyChanged interface which purpose is to notify views when a property has been updated. This is done by invoking OnPropertyChanged method with property name passed as a parameter.

private string property;
public string Property
{
    get { return property; }
    set
    {
        property = value;
        OnPropertyChanged("Property");
    }
}

private string property;

public string Property

{

get { return property; }

set

{

property = value;

OnPropertyChanged("Property");

}

That is not the best way. What if we decide to change the property name and the backing field can also be changed somewhere else? In this case we need to go and manually change the hard-coded property name. So what can be done instead is this:

OnPropertyChanged(nameof(Property));

1	OnPropertyChanged(nameof(Property));

Having passed the parameter this way we can simply go to the property, right click and rename it using Visual Studio renaming tool which will update all calls to this property. Definitely better!

Design Patterns #10: State

Design patterns episode 10 – State

Happy Christmas!! Isn’t it a good time to write a post?
Let me start with an apology. In previous post about patterns (composite) I promised to keep that one week/one pattern schedule but as you can see I have failed. But in the meantime I posted something different (one-bytes #1) so I feel forgiven to some extent. Learnt by experience I promise nothing this time. With that being said we can proceed to the next pattern.

Today’s hero is the State. We all know those simple machines which operation model is frequently very simple but closed within exact patterns. For instance the example given in Head First book – a vending machine. It allows only two or three possible interactions (insert coin, get coin back or get the product) and serves one particular purpose (sell products). Its operation model is base on states: the machine can have a coin inserted, can be out of products, etc. So the machine changes its internal state and this change implicates change of behaviour.

DEFINITION
Let’s take a look at the definition and the diagram.

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

In object-oriented programming the above definition is realised by representing these internal states by different implementations of one interface (or inherited from an abstract class). The important thing is the fact the state changes internally. It is not possible to set state from outside. If we go back and think about strategy pattern we will probably see that these two pattern are similar but that closure to changes from outside is what makes them different.

This the diagram depicting the state pattern and similarly to strategy pattern we have encapsulation of behaviour in a separate class: behaviour of Operation() method in context class is encapsulated in state object. It is possible to have multiple states but transitions between them must be done privately. User of state context must not be able to enforce the context to switch state in any other means than normal operation on the context, intended by designer. We don’t have any public method to set the current state from outside. And that is the key to state pattern.

EXAMPLE
I have used a prepaid electricity meter to show the pattern. It can be thought of as a state machine: it can be switch off, switched on but idle, conducting electricity to appliances or be out of credits. Let’s start with the meter interface:

public interface IMeter
{
    uint Credit { get; }
    AMeterState CurrentState { get; }

    void PowerOn();
    void PowerOff();
    void Start(uint _time);
    void TopUp(uint _value);
}

public interface IMeter

{

uint Credit { get; }

AMeterState CurrentState { get; }

void PowerOn();

void PowerOff();

void Start(uint _time);

void TopUp(uint _value);

}

It exposes two properties: one is the credit that the meter is topped-up with, the other is current state of the meter. Both of them are get-only: there is specific method to top-up and the state cannot be set from the outside. Other than that we have methods to turn the meter on/off, start delivering power (for specified number of cycles) and already mentioned TopUp() method.

public class Meter : IMeter
{
    public uint Credit { get; private set; }
    public AMeterState CurrentState { get; set; }

    public AMeterState OffState { get; private set; }
    public AMeterState OnState { get; private set; }
    public AMeterState MinusState { get; private set; }

    public uint AddCredit(uint _value)
    {
        Credit += _value;
        return Credit;
    }

    public void TakeCredit()
    {
        Credit--;
    }

    public Meter()
    {
        OffState = new OffState(this);
        OnState = new OnState(this);
        MinusState = new MinusState(this);
        Credit = 0;
        CurrentState = OffState;
    }

    public void PowerOn()
    {
        CurrentState.PowerOn();
    }

    public void PowerOff()
    {
        CurrentState.PowerOff();
    }

    public void Start(uint _time)
    {
        CurrentState.Start(_time);
    }

    public void TopUp(uint _value)
    {
        CurrentState.TopUp(_value);
    }
}

public class Meter : IMeter

{

public uint Credit { get; private set; }

public AMeterState CurrentState { get; set; }

public AMeterState OffState { get; private set; }

public AMeterState OnState { get; private set; }

public AMeterState MinusState { get; private set; }

public uint AddCredit(uint _value)

{

Credit += _value;

return Credit;

}

public void TakeCredit()

{

Credit--;

}

public Meter()

{

OffState = new OffState(this);

OnState = new OnState(this);

MinusState = new MinusState(this);

Credit = 0;

CurrentState = OffState;

}

public void PowerOn()

{

CurrentState.PowerOn();

}

public void PowerOff()

{

CurrentState.PowerOff();

}

public void Start(uint _time)

{

CurrentState.Start(_time);

}

public void TopUp(uint _value)

{

CurrentState.TopUp(_value);

}

The implementation of the meter is slightly more complicated. First we need to equip properties from the interface with setters. Next we need properties for each of the possible states. In this case there are three states: OnState, OffState and MinusState. Other than that we have methods to manipulate with credit and a constructor. This is important: we initialise state instances, set credit to zero and set current state to OffState. The last step is four methods from the IMeter interface. These methods don’t have their own implementation but they call current state object to execute its corresponding operations.
Now the abstraction of state class. In this case I’m using abstract class because I need some not public members, force the inheriting classes to set reference in constructor to the meter the state is going to be used with, and reuse some common pieces of code.

public abstract class AMeterState
{
    protected Meter meter;

    public abstract void PowerOn();
    public abstract void Start(uint _time);
    public abstract void PowerOff();

    public AMeterState(Meter _meter)
    {
        meter = _meter;
    }

    public virtual void TopUp(uint _value)
    {
        meter.AddCredit(_value);
        Console.WriteLine("* Your meter has been topped up by {0} credits!", _value.ToString());
        Console.WriteLine("  Current credit: {0}", meter.Credit.ToString());
        if (meter.Credit > 0) { meter.CurrentState = meter.OnState; }
        else { meter.CurrentState = meter.MinusState; }
    }

    public void ReachZero()
    {
        Console.WriteLine("* You have used up all credits. Please top up!");
        meter.CurrentState = meter.MinusState;
    }
}

public abstract class AMeterState

{

protected Meter meter;

public abstract void PowerOn();

public abstract void Start(uint _time);

public abstract void PowerOff();

public AMeterState(Meter _meter)

{

meter = _meter;

}

public virtual void TopUp(uint _value)

{

meter.AddCredit(_value);

Console.WriteLine("* Your meter has been topped up by {0} credits!", _value.ToString());

Console.WriteLine(" Current credit: {0}", meter.Credit.ToString());

if (meter.Credit > 0) { meter.CurrentState = meter.OnState; }

else { meter.CurrentState = meter.MinusState; }

}

public void ReachZero()

{

Console.WriteLine("* You have used up all credits. Please top up!");

meter.CurrentState = meter.MinusState;

}

As you can see states will have all the methods that the meter will call in different states. The TopUp() methods has default implementation because it will the same for OnState and MinusState, method ReachZero will be called whenever the meter runs out of credit. It doesn’t need to be virtual because no override will ever be needed.
The last pieces of code would be actual implementations of the sates. Let’s take a look at just one:

public class OnState : AMeterState
{
    public OnState(Meter _meter)
        : base(_meter) { }

    public override void PowerOff()
    {
        Console.WriteLine("* Meter turned off.");
        meter.CurrentState = meter.OffState;
    }

    public override void PowerOn()
    {
        Console.WriteLine("* Meter already on.");
    }

    public override void Start(uint _time)
    {
        Console.WriteLine("* Starting the meter");
        while ((_time > 0) && (meter.Credit > 0))
        {
            _time--;
            meter.TakeCredit();
            Console.WriteLine("  Powering appliances...");
        }
        if (_time <= 0) { Console.WriteLine("* Meter has completed providing power for requested cycles."); }
        if (meter.Credit <= 0) { ReachZero(); }
    }
}

public class OnState : AMeterState

{

public OnState(Meter _meter)

: base(_meter) { }

public override void PowerOff()

{

Console.WriteLine("* Meter turned off.");

meter.CurrentState = meter.OffState;

}

public override void PowerOn()

{

Console.WriteLine("* Meter already on.");

}

public override void Start(uint _time)

{

Console.WriteLine("* Starting the meter");

while ((_time > 0) && (meter.Credit > 0))

{

_time--;

meter.TakeCredit();

Console.WriteLine(" Powering appliances...");

}

if (_time <= 0) { Console.WriteLine("* Meter has completed providing power for requested cycles."); }

if (meter.Credit <= 0) { ReachZero(); }

}

As you can see each state provide its own implementation of actions possible for the meter (except for TopUp() which as stated earlier can be shared and in this case it is, but it isn’t in OffState where it is overridden to simply write out on console that the meter is off). Note that some of them changes the state – that’s the core of this pattern: the internal change of state.
Having all the states implemented we can see how it works:

static void Main(string[] args)
{
    IMeter meter = new Meter(); //initialize new meter which is in off state
    meter.PowerOn(); //power the meter up
    meter.Start(10); //try to start the meter for 10 cycles which fails due to lack of credit
    meter.TopUp(12); //top up by 6 credits
    meter.Start(10); //start the meter for 10 cycles
    meter.Start(5); //start the meter for 5 cycles which should use up all credits and terminate prematurely
    meter.PowerOff(); //power of the meter
}

static void Main(string[] args)

{

IMeter meter = new Meter(); //initialize new meter which is in off state

meter.PowerOn(); //power the meter up

meter.Start(10); //try to start the meter for 10 cycles which fails due to lack of credit

meter.TopUp(12); //top up by 6 credits

meter.Start(10); //start the meter for 10 cycles

meter.Start(5); //start the meter for 5 cycles which should use up all credits and terminate prematurely

meter.PowerOff(); //power of the meter

}

The above would generate output like this:
As you can see we invoked Start() method on one and the same object and we got three different results which all depended on the state in which the object had been, and some of which changed the state of the object. That’s the way how the state pattern works.

Before I prepared this example I had prepared another: a model of vending machine. It is a WPF app. The reason I decided to go for something different was the fact that it had become a bit unclear in the code. Simple console app is much better to illustrate the pattern. However I did not abandoned the code and you can take a look at this as well. Here’s quick video how it works and the source code you will find at the bottom of this post.

So that’s it for today. Hope you like it 🙂 Before you go please find some useful links below. Enjoy!

Source code – IMeter: TXT file
Source code – Vending machine: GitHub

One-bytes #1: Menu item commands, boxing vs. ToString()

Hello there!
With this post I’m starting new category: one-bytes. These posts will be compiled of two or three shorter forms abut things that don’t qualify for so to say full-size post. Name of the category refers to snack meals, so called one-bite foods: one bite => one byte. Quick to prepare, good to get your taste-buds tingling. Enjoy!

*** #1.1 Binding a command to MenuItem in ContextMenu ***
It happend one time that I had been struggling with binding a command to a MenuItem in ContextMenu. The code was more or less like this:

<Rectangle>
   <Rectangle.ContextMenu>
      <ContextMenu>
         <MenuItem Header="Command" Command="{Binding ???}"/>
      </ContextMenu>
   </Rectangle.ContextMenu>
</Rectangle>

<Rectangle.ContextMenu>

</ContextMenu>

</Rectangle.ContextMenu>

</Rectangle>

It turned out that since ContextMenu is not present in WPF visual tree it was not possible to bind the command as it’s usually done. The solution was to use BindingProxy class that inherits from Freezable.

public class BindingProxy : Freezable
{
    protected override Freezable CreateInstanceCore()
    {
        return new BindingProxy();
    }

    public object Data
    {
        get { return (object)GetValue(DataProperty); }
        set { SetValue(DataProperty, value); }
    }

    public static readonly DependencyProperty DataProperty =
        DependencyProperty.Register("Data", typeof(object), typeof(BindingProxy), new UIPropertyMetadata(null));
}

public class BindingProxy : Freezable

{

protected override Freezable CreateInstanceCore()

{

return new BindingProxy();

}

public object Data

{

get { return (object)GetValue(DataProperty); }

set { SetValue(DataProperty, value); }

}

public static readonly DependencyProperty DataProperty =

DependencyProperty.Register("Data", typeof(object), typeof(BindingProxy), new UIPropertyMetadata(null));

}

Having this class we can create its instance as a resource (in my case it was an user control) and set the Data property to {Binding}:

<UserControl.Resources>
   <local:BindingProxy x:Key="proxy" Data="{Binding}"/>
</UserControl.Resources>

<UserControl.Resources>

<local:BindingProxy x:Key="proxy" Data="{Binding}"/>

</UserControl.Resources>

This will bound the Data property to whatever is set as DataContext in the user control itself. Now, through the BindingProxy instance we can access that DataContext outside the visual tree:

<Rectangle>
   <Rectangle.ContextMenu>
      <ContextMenu>
         <MenuItem Header="Command" Command="{Binding Source={StaticResource proxy}, Path=Data.ViewModelCommand}"/>
      </ContextMenu>
   </Rectangle.ContextMenu>
</Rectangle>

<Rectangle.ContextMenu>

</ContextMenu>

</Rectangle.ContextMenu>

</Rectangle>

This solution was proposed by Thomas Levesque.
Sources:
Blog post by Thomas Levesque
Question on StackOverflow

*** #1.2 String.Format() vs. boxing ***
There is a thing using String.Format() method with value types (such as integers). That thing is the fact that this method takes objects as args and if a value type given as parameter it will be boxed. Boxing is a process when a value type is converted to an object. That involves moving the value from stack to heap and replacing it on a stack with a reference to heap address where the actual value is stored. (More on boxing/unboxing can be found here: [link]).
So, what can be done to avoid that – simply pass arguments with ToString() method invoked. This will save a bit on performance – that’s the theory. So I tested it. I take an array of one million integers and another array with the same amount of doubles and pass them into String.Format() method. And the theory is confirmed – avoiding boxing by invoking ToString() method makes it faster.

To make the results reliable I arranged everything as unit tests run one after another (not parallel) and the actual tests were preceded by a test that did nothing – that is to make sure that the filling arrays in test class constructor does not distort actual test running time. So the results are that the process without boxing is faster by 3,7% for doubles and 4,9% for integers. Please, keep in mind that the test sample was one million values.
Does it mean that it’s no point in invoking ToString()? My opinion is that in this case boxing operation is redundant and not necessary so it should be avoided.

Design Patterns #9: Composite

Design patterns episode 9 – Composite

With unexpected delay but patterns are back! In this episode – composite.

The composite is generally used to model tree-like structures in a way that classes that are using the composite can handle its elements in one particular way without having to distinguish whether an element has children – a composite, or hasn’t – a leaf (in other words, whether we can go further down the tree or element is a dead-end).

The first thing that comes up when thinking about that kind of structure would be a directory tree where folders are composites and files are leafs. Or any other structure alike: corporate structure (managers and subordinates), online shops (categories and concrete items) and many many more.

DEFINITION
Let’s see how the Head First book defines this pattern:

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and composition of objects uniformly.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

So, in other words we have tree structure of objects and collection of objects and the client doesn’t need to care about if it’s a leaf or a composite. This is the key feature of this pattern. For instance, let’s think about file system where we have files and directories. Both of them are elements of file system and should be treated the same: the client can perform the same operations on both – rename, delete, get size etc. But obviously we can do more things with directories (as this is a collection of files and directories), therefore composite pattern isn’t applicable here (of course you could use typecasting to make it work but that’s a different thing).
The diagram shows what discussed above – both concretions are treated the same, nothing different can client do with one or the other type. The diagram presented here is different than what’s in the book. The book adds further methods: add(), remove(), getChild(). But isn’t that inconsistent with the definition? How can you add a further child to a leaf? You could throw an exception but wouldn’t that violate the Interface Segregation Principle? That kind of issues have been greatly discussed here by the guy who I quoted on multiple occasions.
So, to conclude this aspect of the pattern – my opinion is that we should stick to ISP and not force any class to implement something that the class doesn’t use. Period. Let’s move on to code example.

EXAMPLE

In our code example we’re going to build a store’s menu. Let’s start with the abstraction:

public interface IStoreElement
{
    string Name { get; set; }
    string ListOut(int indent = 0);
}

public interface IStoreElement

{

string Name { get; set; }

string ListOut(int indent = 0);

}

Our IStoreElement consist of name property and a method to list self in the menu: there will be different implementations of this method for leaves and composites. This method can take optional argument as we want to nicely format the menu by indentation of sub-components.
Now the leaf class:

public class StoreItem : IStoreElement
{
    public string Name { get; set; }

    public StoreItem(string _name)
    {
        Name = _name;
    }

    public string ListOut(int indent = 0)
    {
        string result = "";
        for (int i = indent; i > 0; i--)
        {
            result += "-";
        }
        result += String.Format("Item: {0}", Name);
        return result;
    }
}

public class StoreItem : IStoreElement

{

public string Name { get; set; }

public StoreItem(string _name)

{

Name = _name;

}

public string ListOut(int indent = 0)

{

string result = "";

for (int i = indent; i > 0; i--)

{

result += "-";

}

result += String.Format("Item: {0}", Name);

return result;

}

Leaf’s implementation of ListOut() method works that it returns a string with given number of dashes and its name.
And finally composite class:

public class StoreCategory : IStoreElement
{
    public string Name { get; set; }
    private IList<IStoreElement> members;

    public StoreCategory(string _name, IList<IStoreElement> _members)
    {
        Name = _name;
        members = _members;
    }

    public string ListOut(int indent = 0)
    {
        string result = "";
        for (int i = indent; i > 0; i--)
        {
            result += "-";
        }
        result += String.Format("Category: {0}", Name);
        foreach (IStoreElement element in members)
        {
            result += String.Format("\n{0}", element.ListOut(indent + 1));
        }
        return result;
    }
}

public class StoreCategory : IStoreElement

{

public string Name { get; set; }

private IList<IStoreElement> members;

public StoreCategory(string _name, IList<IStoreElement> _members)

{

Name = _name;

members = _members;

}

public string ListOut(int indent = 0)

{

string result = "";

for (int i = indent; i > 0; i--)

{

result += "-";

}

result += String.Format("Category: {0}", Name);

foreach (IStoreElement element in members)

{

result += String.Format("\n{0}", element.ListOut(indent + 1));

}

return result;

}

This class is equipped with private list of objects that implement our base interface. This list can be set in constructor.
The ListOut() method starts with the same thing that counterparting method in leaves but before returning the value recursively invokes the same method for all IStoreElements that the composite holds in its private list. This invocation takes indent parameter increased by 1. This way we achieve that nice formatting of the list once requested in the topmost component.
Now, let’s see how it work all together:

static void Main(string[] args)
{
    IStoreElement myStore = generate();
    Console.WriteLine(myStore.ListOut());
}

static IStoreElement generate()
{
    IStoreElement subcat1 = new StoreCategory("Foods",
        new List<IStoreElement>
        {
                    new StoreItem("Bread"),
                    new StoreItem("Veggies"),
                    new StoreItem("Cheese"),
                    new StoreCategory("Drinks",
                    new List<IStoreElement>
                    {
                        new StoreItem("Juice"),
                        new StoreItem("Mineral water"),
                    })
        });
    IStoreElement subcat2 = new StoreCategory("Chems",
        new List<IStoreElement>
        {
                    new StoreItem("Toothpaste"),
                    new StoreItem("Shampoo"),
                    new StoreItem("Soap")
        });
    IStoreElement item1 = new StoreItem("Painkillers");
    IStoreElement item2 = new StoreItem("Lottery ticket");
    IStoreElement result = new StoreCategory("Local shop",
        new List<IStoreElement>
        {
                    subcat1,
                    subcat2,
                    item1,
                    item2
        });
    return result;
}

static void Main(string[] args)

{

IStoreElement myStore = generate();

Console.WriteLine(myStore.ListOut());

}

static IStoreElement generate()

{

IStoreElement subcat1 = new StoreCategory("Foods",

new List<IStoreElement>

{

new StoreItem("Bread"),

new StoreItem("Veggies"),

new StoreItem("Cheese"),

new StoreCategory("Drinks",

new List<IStoreElement>

{

new StoreItem("Juice"),

new StoreItem("Mineral water"),

})

});

IStoreElement subcat2 = new StoreCategory("Chems",

new List<IStoreElement>

{

new StoreItem("Toothpaste"),

new StoreItem("Shampoo"),

new StoreItem("Soap")

});

IStoreElement item1 = new StoreItem("Painkillers");

IStoreElement item2 = new StoreItem("Lottery ticket");

IStoreElement result = new StoreCategory("Local shop",

new List<IStoreElement>

{

subcat1,

subcat2,

item1,

item2

});

return result;

}

We generate the list and then print to the console the string returned by ListOut().

To sum things up: he Composite Pattern is used to represent tree-like structures where all their elements can be treated uniformly, where single components are called leaves and collections of components are called composites. The pattern can be equipped with methods to modify the content but this lead to violation of Interface Segregation Principle.

Next week: the State Pattern. I hope that this time without any delay. Check the links and source code below. Thank you!

Composite pattern by Christopher Okhravi: link [YouTube]
Composite vs. Decorator by Christopher Okhravi: link [YouTube]
Composite pattern by Michael: link [YouTube]
Source code: TXT file

Design Patterns #8: Iterator

Design patterns episode 8 – Iterator

Today’s pattern is the Iterator – an easy way to cycle through collections without worrying how it is achieved – in simple words. Let’s see what the Head First book has to say about that.

DEFINITION

The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying implementation.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

This is achieved by two interfaces: one abstracts the iterator, the other abstracts the aggregator. To make things clear – the aggregator is a class that provides a collection we want to iterate through.

So, there is a class called ConcreteAggregator that has a collection of objects. The diagram above depicts a generic version of the pattern (this not a must, you can write your own specific iterator) so the collection stores objects of type T. The ConcreteAggregator doesn’t want to allow direct access to that collection so it implements the IAggregator interface to allow the client to use the iterator by invoking GetIterator() method which returns ConcreteIterator which in turn implements the IIterator interface. This interface is the core of the pattern: it provides methods to actually iterate through the collection: i) Reset() to move index pointer to the start of the collection, ii) HasNext() to indicate whether there are more elements in the collection, and finally iii) Next() to get an element from the collection.

ITERATORS IN .NET

The .NET Framework uses this pattern widely in collections. To make long story short – in System.Collections (or System.Collections.Generic) namespace you can find IEnumerable interface which has only one method: GetEnumerator() – sounds familiar, right? Most of the collections implement this interface – Lists or dictionaries for instance, not to look far. This method returns an object the implement IEnumerator interface. In this case this interface is slightly different:

This post	.NET namespaces	Explanation
void Reset()	void Reset()	no difference
bool HasNext()	bool MoveNext()	In .NET interface this method moves the pointer to next element and returns: true – if advanced successfully without passing the end, false – if passed the last element and set the pointer to the first element
<T> Next()	object or <T> Current { get; }	In .NET this property returns object at current position of the pointer without moving to next element

EXAMPLE

In the example we will create a book library. This class will store books in a private list but will expose an iterator. Let’s start with the interfaces:

public interface IIterator<T>
{
    void Reset();
    bool HasNext();
    T Next();
}

public interface IAggregator<T>
{
    IIterator<T> GetIterator();
}

public interface IIterator<T>

{

void Reset();

bool HasNext();

T Next();

}

public interface IAggregator<T>

{

IIterator<T> GetIterator();

}

They’ve been already discussed above so the only thing I would like you to pay attention to is the fact that they’re generic.
Next step – implement the iterator:

public class LibraryIterator : IIterator<string>
{
    private string[] books;
    private int currentIndex;

    public LibraryIterator(IList<string> _books)
    {
        currentIndex = 0;
        books = new string[_books.Count];
        for (int i = 0; i < books.Length; i++)
        {
            books[i] = _books[i];
        }
        Reset();
    }

    public void Reset()
    {
        currentIndex = -1;
    }

    public bool HasNext()
    {
        if (books.Length > currentIndex + 1) { return true; }
        return false;
    }

    public string Next()
    {
        try
        {
            currentIndex++;
            return books[currentIndex];
        }
        catch
        {
            Reset();
            return Next();
        }
    }
}

public class LibraryIterator : IIterator<string>

{

private string[] books;

private int currentIndex;

public LibraryIterator(IList<string> _books)

{

currentIndex = 0;

books = new string[_books.Count];

for (int i = 0; i < books.Length; i++)

{

books[i] = _books[i];

}

Reset();

}

public void Reset()

{

currentIndex = -1;

}

public bool HasNext()

{

if (books.Length > currentIndex + 1) { return true; }

return false;

}

public string Next()

{

try

{

currentIndex++;

return books[currentIndex];

}

catch

{

Reset();

return Next();

}

To complicate the code a bit the implementation will use an array to store the values, beside that we also have an integer to indicate current position. In the constructor we initialise the array of values and copy them from the list passed as an argument. The last thing we need to do in the constructor is to set the index indicator to Reset() the position indicator. The only thing that Reset() method do is to set value of position indicator to -1. Why -1 not 0? That is because we use Next() method to get values: this method first increments the indicator and then extracts the value. Method HasNext() simply check if position index increment operation would not exceed the length of the array of values.

public class Library : IAggregator<string>
{
    private List<string> books;

    public Library()
    {
        books = new List<string>()
            {
                "Lord of the Rings",
                "Dune",
                "Brave New World",
                "The Road",
                "20.000 Leagues Under the Sea",
                "The Call of Cthulhu",
                "Bloody Meridian"
            };
    }

    public IIterator<string> GetIterator()
    {
        return new LibraryIterator(books);
    }
}

public class Library : IAggregator<string>

{

private List<string> books;

public Library()

{

books = new List<string>()

{

"Lord of the Rings",

"Dune",

"Brave New World",

"The Road",

"20.000 Leagues Under the Sea",

"The Call of Cthulhu",

"Bloody Meridian"

};

}

public IIterator<string> GetIterator()

{

return new LibraryIterator(books);

}

The Library class is very simple – in its constructor we fill the list of books and implement the IAggregator interface: the GetIterator() method returns new LibraryIterator with list of books passed as an argument.
And everything works perfectly. Here’s some code to test that:

static void Main(string[] args)
{
    IAggregator<string> myLib = new Library();
    IIterator<string> myLibIterator = myLib.GetIterator();

    while (myLibIterator.HasNext()) // iterating through
    {
        Console.WriteLine(myLibIterator.Next());
    }

    Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // HasNext() is false when reached the last element

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // what happens when tried HasNext() in the middle of the iterator

    myLibIterator.Reset();

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() after Reset();

    Console.WriteLine("---\nNext element: {0}\n---", myLibIterator.Next()); // what happens when tried Next() method

    while (myLibIterator.HasNext()) // iterating through again this time starting not from the begining
    {
        Console.WriteLine(myLibIterator.Next());
    }
}

static void Main(string[] args)

{

IAggregator<string> myLib = new Library();

IIterator<string> myLibIterator = myLib.GetIterator();

while (myLibIterator.HasNext()) // iterating through

{

Console.WriteLine(myLibIterator.Next());

}

Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // HasNext() is false when reached the last element

Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // what happens when tried HasNext() in the middle of the iterator

myLibIterator.Reset();

Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() after Reset();

Console.WriteLine("---\nNext element: {0}\n---", myLibIterator.Next()); // what happens when tried Next() method

while (myLibIterator.HasNext()) // iterating through again this time starting not from the begining

{

Console.WriteLine(myLibIterator.Next());

}

And that’s it – the iterator in its full swing:
Here’s couple of links that may also be useful:
Why iterator is important: [YouTube] by Christopher Okhravi
Another code example: [YouTube] by Michael

Source code: [TXT file]

Design Patterns #7: Template Method

Design patterns episode 7 – Template Method

This post is about template method pattern. Those who are familiar with the Head First book may be wondering where’s facade. The answer to that question is that I deliberately decided to skip the facade at this point. I will definitely come back to this, but maybe next time. Now, let’s move on to the template method.

DEFINITION

The Template Method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

What the above mean? It means that the pattern is built on base abstract class which has a public method which defines our algorithm by invoking in intended order some other methods which may be overridden by subclasses. The algorithm’s member methods may provide default implementation of be abstract forcing the subclasses to provide their own unique implementation.

EXAMPLE
Most of the examples you can find is based on preparation of pizza, coffee etc. And they’re really good. Pizza for instance: when you’re cooking a pizza no matter what style you basically do the same: prepare dough, add sauce, toppings, put it into oven and cut. That’s the algorithm. But you certainly do different dough for American pizza and for traditional Italian pizza, you add different toppings for vegetarian pizza and for meat pizza – and that’s the where we may want to override our sub-methods of the algorithm.

The code below will not be about pizzas, it’s going to be a generic code that does nothing but show how the pattern may be implemented.
Let’s take a look at our base class:

public abstract class TemplateBase
{
    public void TemplateMethod()
    {
        subOperation0();
        subOperation1();
        subOperation2();
        if (ExecuteOptional) { subOperation3(); }
    }

    public void subOperation0()
    {
        Console.WriteLine("Start:\nOperation 0 - cannot be overridden");
    }

    public virtual void subOperation1()
    {
        Console.WriteLine("Operation 1");
    }

    public abstract void subOperation2();

    public virtual void subOperation3()
    {
        Console.WriteLine("Operation 3 - optional");
    }

    public bool ExecuteOptional
    {
        get;
        set;
    }
}

public abstract class TemplateBase

{

public void TemplateMethod()

{

subOperation0();

subOperation1();

subOperation2();

if (ExecuteOptional) { subOperation3(); }

}

public void subOperation0()

{

Console.WriteLine("Start:\nOperation 0 - cannot be overridden");

}

public virtual void subOperation1()

{

Console.WriteLine("Operation 1");

}

public abstract void subOperation2();

public virtual void subOperation3()

{

Console.WriteLine("Operation 3 - optional");

}

public bool ExecuteOptional

{

get;

set;

}

As you can see our TemplateMethod() is not marked as virtual therefore it cannot be overridden – this is the skeleton of the algorithm. In its body this method invoke all member methods – subOperations from 0 to 3. Interesting thing is that the last member method will be executed only if a condition is true. This is called a hook. This is one way to alter the invocation list of the algorithm. You don’t need to use is but it’s good to know. Besides that we have combination of methods with default implementation, abstract methods and those you cannot overwrite. In our case only one methods needs to be implemented in a subclass – let’s take look:

public class ConcreteTemplate : TemplateBase
{
    public override void subOperation1()
    {
        Console.WriteLine("Overriden operation 1");
    }

    public override void subOperation2()
    {
        Console.WriteLine("Operation 2 - does not have default implementation");
    }
}

public class ConcreteTemplate : TemplateBase

{

public override void subOperation1()

{

Console.WriteLine("Overriden operation 1");

}

public override void subOperation2()

{

Console.WriteLine("Operation 2 - does not have default implementation");

}

So, our concrete implementation overwrites one method with implementation in base class and provides implementation of one abstract class. Simple, so let’s see how it works:

static void Main(string[] args)
{
    TemplateBase tm = new ConcreteTemplate();
    tm.TemplateMethod();
    tm.ExecuteOptional = true;
    tm.TemplateMethod();
}

static void Main(string[] args)

{

TemplateBase tm = new ConcreteTemplate();

tm.TemplateMethod();

tm.ExecuteOptional = true;

tm.TemplateMethod();

}

To witness the template method we instantiate new ConcreteTemplate and observe how it behaves – with optional method executed and without.

And that’s the template method pattern. The best explanation of this pattern I’ve found so far is in the Head First book but below you will find also one link to a YouTube video with Phil Japikse – you may find it useful.
Thanks for today and expect the next pattern next week.

Design Patterns: Template Method – YouTube
Source code: TXT file

Design Patterns #6: Adapter

Continuing with design patterns. Time for Adapter. This pattern is a structural pattern whose purpose is to convert interface (in a meaning of public members of the class, not necessarily interface as a programming language feature) so the class is usable with client’s code. The Head First book defines this pattern as:

The Adapter Pattern converts the interface of a class into another interface the client expects. Adapter lets classes work that couldn’t otherwise because of incompatible interfaces.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

Generally, it may be said that the adapter pattern wraps an object that cannot be used by a client and exposes an interface that allow the client to use that object. Let’s take a look at the diagram:

So, we have a client that wants to use an object that implements IExpected interface, however we already have a class that does what we need but doesn’t have a compatible interface (unsupported class). So, to solve the problem we need an adapter. The adapter will have all public members that the client expects – will implement the IExpected interface and at the same time will privately wrap an instance of unsupported class (passed in a constructor, for instance). Once the client calls the adapter, the adapter will in turn call the wrapped unsupported class and return results to the client (and if required convert them to what the client expects). And that’s it, simple as that.

EXAMPLE
Let’s take a look at code example now. We have a class that calculates area and perimeter of a rectangle. (These calculations are very simple but to give the example a little bit more depth think of them as of very sophisticated and complicated). That class operates on double type. Our client, however wants to calculate area and perimeter of squares only and operates on integers. We could i) write a new class to handle that but we don’t want to do that because we already have a class that is capable to perform such calculations (square is a rectangle after all, right?); ii) modify our client to work with the existing class, but again we don’t want to break anything elsewhere (OCP right?). That’s why the right solution here is the adapter.
Let’s compare what we have and what we need:

public class RectangleHandler
{
    public double Area(double a, double b)
    {
        return a * b;
    }

    public double Perimeter(double a, double b)
    {
        return 2 * a + 2 * b;
    }
}

public class RectangleHandler

{

public double Area(double a, double b)

{

return a * b;

}

public double Perimeter(double a, double b)

{

return 2 * a + 2 * b;

}

public interface ISquareHandler
{
    int GetArea(int a);
    int GetPerimeter(int a);
}

public interface ISquareHandler

{

int GetArea(int a);

int GetPerimeter(int a);

}

So, the differences are: i) types (already mentioned int vs. double), ii) method names, iii) number or arguments required for counterparting methods.
Now the adapter. First of all it needs to wrap the already existing class and set its instance by passing it through constructor; then we need to implement methods required by IExpected interface in a way that they call the wrapped object and return values converted to integers.

public class RectangleAdapter : ISquareHandler
{
    private RectangleHandler adaptedHandler;

    public RectangleAdapter(RectangleHandler _adapted)
    {
        adaptedHandler = _adapted;
    }

    public int GetArea(int a)
    {
        int result = (int)adaptedHandler.Area((double)a, (double)a);
        return result;
    }

    public int GetPerimeter(int a)
    {
        int result = (int)adaptedHandler.Perimeter((double)a, (double)a);
        return result;
    }
}

public class RectangleAdapter : ISquareHandler

{

private RectangleHandler adaptedHandler;

public RectangleAdapter(RectangleHandler _adapted)

{

adaptedHandler = _adapted;

}

public int GetArea(int a)

{

int result = (int)adaptedHandler.Area((double)a, (double)a);

return result;

}

public int GetPerimeter(int a)

{

int result = (int)adaptedHandler.Perimeter((double)a, (double)a);

return result;

}

Let’s write a quick test:

static void Main(string[] args)
{
    ISquareHandler squareHandler = new RectangleAdapter(new RectangleHandler());
    Console.WriteLine("Square edge length:");
    int length = int.Parse(Console.ReadLine());
    int area = squareHandler.GetArea(length);
    int perimeter = squareHandler.GetPerimeter(length);
    Console.WriteLine("Square: {0}x{0}", length);
    Console.WriteLine("Area: {0}", area);
    Console.WriteLine("Perimeter: {0}", perimeter);
}

static void Main(string[] args)

{

ISquareHandler squareHandler = new RectangleAdapter(new RectangleHandler());

Console.WriteLine("Square edge length:");

int length = int.Parse(Console.ReadLine());

int area = squareHandler.GetArea(length);

int perimeter = squareHandler.GetPerimeter(length);

Console.WriteLine("Square: {0}x{0}", length);

Console.WriteLine("Area: {0}", area);

Console.WriteLine("Perimeter: {0}", perimeter);

}

Everything works perfectly.

Object adapter vs. Class adapter
The explanation and code example is an object adapter. This means that the adapter works with a concrete instance of adapted object. Advantage of this solution is that this type of adapter will work also with objects of classes which are derived from adapted superclass.
There is also another adapter-type pattern called class adapter. In this type you don’t need an instance of adapted class, instead the adapter class inherits from both: expected class (or interface) and adapted class. Remember that inheriting from more than one superclass is not possible, what could be done is to create new class that inherits from a class that needs to be adapted and implements expected interface. This approach may also be useful but keep in mind that it looses the advantage of composition over inheritance.

To sum things up: adapters are extremely useful everywhere there is a need to use something that can do what we need but doesn’t have compatible interface.
Plan for next week: Facade

Don’t forget to check the links below!

Christopher Okhravi about Adapter Pattern: [YouTube]
Source code: [TXT file]