Design Patterns – Command and Strategy

These two patterns are quite often mixed up, since they both perform an action when invoked.

However there are quite substantial difference:
1) Command should only be used as a trigger for a more complex action and should have no computational logic.
2) Strategy in the meantime encapsulates logical operations.

In simple terms command should have as little logic as possible, whereas strategy might encapsulate some complex calculations. It is also possible that a command triggers a strategy to be executed.

An example from WPF would be a particular control bound to an instance of ICommand which in turn could run a particular strategy.

Design Pattern – Abstract Factory

Abstract Factories are used to provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Consider an example where we need to create a service for sending data. The data could be sent using various means: by calling a web service, WCF service or by using plain sockets.

To avoid tight coupling the object that sends the data should not be aware of how the data is sent. That’s where abstract factory comes into play. Assuming that all senders implement a  common interface, all the code has to do is call the method that accepts data in whichever format. The benefit of that approach is that we can later easily substitute the protocol for sending data without making any changes to the object that sends data.

In addition, the abstract factory allows the creation of multiple instances of the class responsible for sending data. This is a very useful property when we use dependency injection. The abstract factory can be injected through the constructor and the object responsible for sending data is free to create as many instances of the service as it requires.

That pattern not only solves the coupling problem and separation of concerns, but also allows for better unit testing, since the abstract factory can be very easily mocked.

Design Pattern – Adapter

The purpose of the adapter pattern is actually quite simple. It converts one interface to another one, thus making it possible for classes to work together where the interfaces are different.

Real World Example

Because it’s such a common pattern I had to think for a while before coming up with an example.

Say, our application has to export some data in various formats – excel, pdf etc. It would be quite likely that third party libraries for each of the formats have different interfaces. We could of course write a switch statement, but the better solution would be to wrap each of the third party libraries into a class that implements a common interface. Then all we have to do is resolve the wrapper based on the format. Since the wrapper would implement a common interface the task of exporting data become relatively simple

A new compression algorithm?!

I started a project yesterday. The idea is quite simple take some data and embed it into an image. The size of the image directly correlates to the data that you can embed in it. So during my testing I have created a RAR archive with maximum compression level and embedded it into a PNG image.

I tried to keep everything simple and the algorithm follows the following steps:

• Store size of data in bytes, so we have to convert int to an array of 4 bytes. Easily done with the help of BitConverter
• Store the name, again the data needs to be converted to bytes

Nothing to be excited about so far.

However once I embedded the already compressed data in RAR format into a PNG image, the size has reduced even further, by 20%! Since PNG is a loss-less format, my only explanation is it does some compression using how the pixels are arranged.

I will do further testing and if it does turn to be true and would definitely write a new compression algorithm. Man I probably already revealed too much!

I will keep you posted.