Rss 2.0 via FEED
Ken Hughes... - DesignPatterns
Productivity, Technology and Automating Everything...
    
 

In the first version of my GPS Library software (written in VB6) I had a 'Protocol' property that indicated which protocol we were using (for example Garmin, Magellan, NMEA etc). Then, every time we needed to do something at the protocol layer (Sending or Receiving data) we had an if statement :

If gps.Protocol = GpsProtocol.Garmin Then
     ' Do it this way
EsleIf gps.Protocol = GpsProtocol.Magellan Then
     ' Do it that way
Else
     ' Do it the other way

Horrible and messy !! Adding a new protocol meant going back to every function and amending it.

In the new .NET version, it's much more object oriented and I've used a number of software design patterns.

To solve the above problem I used a Factory pattern. The Factory pattern allows you to create objects but let the client decide what type those objects should be. So, I can basically let the client set the Protocol property and then, depending on that setting create a different object for each protocol.

I start with a base class that all the 'codec' classes inherit from, then in the 'creation' (when the client creates the object) I look at the Protocol property and choose which concrete class to return:

GpsCodec is the base class and the concrete classes are GarminCodec, MagellanCodec etc. I have a static method in the base class called 'CreateCodec' that takes a 'Protocol' parameter. So it looks like this

public static GpsCodec CreateCodec(GpsProtocol protocol)
{
     switch (protocol)
     {
          case GpsProtocol.Garmin:
               return new GarminCodec();
               break;
          case GpsProtocol.Magellan:
               return new MagellanCodec();
               break;
          default:
               return null; // error
               break;
     }
}

So now I can simply create a codec class based on the Protocol property and use that for all the communication to / from the device. Adding a new protocol is simply a case of creating the new class and modifying the CreateCodec method - much simpler.

Watch this space for the free .NET GPS Library (including source).

Posted: Sunday, November 12, 2006 3:57:31 PM (GMT Standard Time, UTC+00:00)  #   Comments [0]
TAGS: .NET | C Sharp | Design Patterns | Development | GPS

In the first version of my GPS Library (written in VB6) I had a big horrible multiple nested if statement that handled the intelligence behind what to do when a new frame of data was received - if we were sending Waypoints to the GPS and the frame was an Acknowledgement (ACK) then we would send the next one, if it was a Not Acknowledgement (NACK) then we'd retransmit the last one - everything that happened depending on the current context (what we are currently doing). As there were about 20 different things we could be doing at the time and about 20 odd frame types, this was real messy and probably had a Cyclometric Complexity of 9292736592 (or more)...

My .NET version of the GPS Library makes extensive use of Software Design Patterns - to solve the problem above I used a 'State' pattern.

The State pattern is used where your software has multiple states and various actions or stimulations that make it change between states (but it is always going to be in one of the predefined states). I guess it a pretty common pattern for communication systems.

I have a base class called GpsState, that contains all an (overrideable) method for each action and stimulation and each method has a default implementation of something like

throw new Exception("Invalid action for state :" + this.StateName);

All the state classes inherit from this base state class.

Lets take (much simplified) sending Waypoints as the example:-

The GPS object has a reference to the current state class. This starts off in the stateIdle (doing nothing). We then call the stateIdle.WriteWaypoints() function. In this function we send the first Waypoint and change the state to stateWritingWaypoints.
The stateWritingWaypoints overrides the 'GotACK' method and provides it own implementation (which is simply to send the next Waypoint). If any of the other methods are called whilst in the stateWritingWaypoints then the implementation from the base class is called and the caller receives an exception.
When I've sent the last Waypoint then I change state back to stateIdle so that other actions can be called again

So my class for stateWritingWaypoints handles writing Waypoints and nothing else - this makes the code really clean and simple. The downside is that you end up with many more (small) classes in your code.

Watch this space for the source to the free .NET GPS Library.

Posted: Sunday, November 12, 2006 3:26:18 PM (GMT Standard Time, UTC+00:00)  #   Comments [0]
TAGS: .NET | Design Patterns | Development | GPS

Singleton Design Pattern, is a solution to a common problem in the software domain where you want to create ONE AND ONLY ONE instance of an object/class.

Put simply, it stops client applications creating their own instances of an object and routes all creation of the object through one method. If an instance of the class already exists then that instance is returned, if an instance of the class does not exist then a new instance is created.

So, no matter how many clients access the class there is only ever one instance (that all clients access)

Here's some sample code of how to achieve a Singleton class :

using System;

using System.Collections.Generic;

using System.Text;

 

namespace KenAndSarah.GpsControl

{

    public class GpsControl

    {

        private static GpsControl instance = null;

 

        private GpsControl()

        {

            // do not allow a public constructor

        }

 

        // call this to get (or create) a reference to the class

        public static GpsControl GetGpsControl()

        {

            if (instance == null)

                instance = new GpsControl();

            return instance;

        }

    }

}

 

So to clients would simply use it like this

        GpsControl gps = GpsControl.GetGpsControl();

 

Any subsequent clients who make the same call get a reference to the already created instance of the class.

Posted: Friday, October 06, 2006 3:50:20 PM (GMT Daylight Time, UTC+01:00)  #   Comments [0]
TAGS: .NET | C Sharp | Design Patterns | Development | Software

Blank entry, simply to list out the categories.

Posted: Saturday, January 01, 2005 5:32:53 PM (GMT Standard Time, UTC+00:00)  #   Comments [0]
TAGS: Archiving | C Sharp | Code Generation | Exchange | Family | Mountaineering | PHP | RSS | Scripting | Support | Technical | .NET | Design Patterns | Hardware | Dasblog | Running | Tools | Development | Software | TaHoGen | GPS
     
 
 
Copyright © 2008 Ken Hughes. All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License.