Meta

Development

Let us have a look at the eventing or observer pattern. This pattern is based on the raising and handling of events. Events are a mechanism for the communication between object that allow us to build loosely coupled applications that can be easily extended.

At a high level this pattern functions as follows:
An object (known as the Publisher) defines a contract (delegate method) to which other objects (knows as Subscribers) must comply in order to be notified of a certain condition occurring in the Publisher object. This is achieved as follows, when a certain state is reached in the Publisher object an event will be raised, which will then trigger all the Subscriber objects to react by executing the method defined within the individual Subscriber objects that matches the delegate method as defined in the Publisher.

Now let us have a look at an example:

First let us create the Publisher, here we have to do three things:
1. Define a delegate which will act as the contract between the Publisher and Subscribers.
2. Define an event based on the delegate.
3. Raise the defined event.

Extension methods allow us to add methods to existing classes without changing the class’ source code, nor by inheriting from the class. Extension methods are more relevant when wanting to add a method to a class from which one cannot inherit, such as sealed classes.
Just note, you cannot use extension methods with a static class as extension methods require an instance variable for an object in order to be utilised.
Let us look at an example, here we will add an extension method to the string class, which is a sealed class (i.e. you cannot inherit from this class).

A delegate is a form of a type-safe function pointer. More simply put, it is an object that knows how to call a method, i.e. a reference to a method. Delegates are useful as they assist us in writing flexible and extendable applications.

Delegates are useful when using the eventing design pattern also known as the observer pattern. The eventing or observer pattern consists of an object, called the subject or publisher, which maintains a list of dependent objects, called observers or subscribers, and notifies them automatically of a state change in the subject-object by raising an event and then calling a method on the observer objects by using a delegate. We will cover this pattern in more detail when I cover events in a separate post.

So, in this basic example we have a class KillerRobotActuator which declares a delegate:

public delegate void KillerRobotActionHandler(KillerRobot robot);

Any method that complies to this signature can then be added to this delegate and in the DoAction method where the following is executed:

actionHandler(robot);

All the methods that have been added to the actionHandler will then be executed.
We can see in the Main method of the Program class that a new KillerRobotActionHandler is declared and three method references are added to it as below:

And then finally the DoAction method on KillerRobotActuator is executed, passing in the above declared actionHandler containing references to the three methods:

robotActuator.DoAction(“The Geek”,actionHandler);

All three the methods that are referenced by the actionHandler comply to the signature defined in the delegate declaration in the KillerRobotActuator class. i.e. a void return type and an input parameter of type KillerRobot.
It is also worth mentioning that of the methods referenced, two are contained in a separate class RobotActions and the third is a static method declared in the Program class, so methods from multiple different class locations can be added as long as they comply to the signature of the delegate declares.

Generics refer to the method of creating classes and methods in a way that defers the specification of the type or types associated with the class or method until it is declared and instantiated.

What this means in plain english is that you can define a single class or method that can be utilised with multiple types, thus resulting in less and tidier code.

So let us have a look at an example. Firstly let us look at some code that is not generic. Here we have a class which consist of a list of integers, it has a default constructor as well as two methods, one to add an integer to the list and the other to return the sum of all the integers in the list.

This is very straight forward, however if I would like to use this class with a data type other than int (for example a float or a double) I would need to define a new class for each data type. This can be overcome by utilising Generics. Below is an example of how this can be implemented:

In some cases you might want to put a restriction on the types that can be utilised to implement a generic class of method, this can be achieved by utilising constraints. For example the class we defined above can be restricted to types that implement the IComparable interface by simple changing the first line as follows:

public class KillerRoboticsGenericList<T> where T : IComparable

Some additional examples of constraints are:

where T : Product

This restricts the type of T to an implementation of the class Product or any of its child classes.

where T : struct

This restricts the type of T to the value type struct.

where T : new()

This restricts the type of T to an object with a default constructor.

Multiple Constraints can also be appled at the same time, for example:

A Generic class can be defined to utilise multiple types, for example:

public class KillerRoboticsGenericList<T,U,V>

It is also worth mentioning that the default c# List class used in the above examples also utilises generics, along with all the other predefined c# collections contained in System.Collections.Generic.

I hope this post has been useful and I will be posting on some additional C# topics, such as Delegates, Lamda Expressions, LINQ, Extension Methods, etc. over the next few months.

Many books have been written on the topic of robot building, ranging from very basic to extremely complex, but I have seldom come across a book that gets the balance right. Robot Builder’s Bonanza by Gordon McComb hits the sweet spot.

The book provides a vast amount of detail on the electronics, mechanics and programming required to build a robot. Concepts like movement (for both wheeled and legged robots), sensors (to make your robot perceive its environment and conditions), the pros and cons of different Micro-controllers, as well as many other actuators (that allow the robot to change its environment in some way) are all covered.

At the start of each section, a brief introduction to the field is given that includes explanations of key concepts (such as resistors and capacitors in the case of the electronics section) to the tools used (such as drills and screws in the case of the mechanical section). The book includes over 100 projects as examples to illustrate the concepts covered.

The book, in both print and content, is of very high quality. It is very clearly written and provides many diagrams, pictures and schematics, making it easy to understand even the more complex topics covered, for example robotic vision, robotic interpretation of sounds or the choice of which micro-controllers to use as your robots’ brain.

I would very highly recommend Robot Builder’s Bonanza to anyone interested in getting started in robot building or even someone who is currently building robots. It is not just a great book for learning the basics and getting started, but it is also a great reference guide to complex topics as well as a source of inspiration.

As far as Robotics books go this is one of the best, do yourself a favour and pick up a copy today.

When working on legacy systems you may sometimes find that a wide variety of technologies have been used, and short of rewriting a huge amount of code the only thing that can be done is to create some functionality to map between the different technologies utilised.

I had a scenario where I had to integrate 2 legacy applications utilising different technologies for database access, one utilised ADODB and the other ADO.NET. Due to time constraints I could not change the underlying code of the systems and rather decided to create a helper class to map an ADO.NET DataTable to an ADODB RecordSet in order to facilitate the integration.

My DTtoRSconvert is a static class that resides in the Core.Data.Help namespace. It contains a static method ConvertToRecordSet that takes a DataTable as a parameter and returns a RecordSet. It also has one static private method TranslateType which is used to map between the DataTable and RecordSet Data types.

This will be the last Bite Size C# post revolving around CSV and XLS files (for a while at least). The next one will be on a different and probably a bit more exciting topic.

Today we will look at my XLS File Merger, which resides in the Core.XLS namespace of my Core.dll library. It is a static class with one static method MergeFiles. The purpose of this method is to merge 2 or more XLS files into a single file, i.e. taking the worksheets of 2 or more files and combing them into a single file. The MergeFiles method takes 2 arguments: a list of locations of files to be merged (filePathList) and the destination file that will be created (outputFile).