Advantages of static factories over constructors:

• Static factory instances have names but constructors do not.
• Static factories can have two methods named differently but taking the same number and type of parameters.
• Subclassing isn't possible but inheritance isn't always the best way to reuse code.

Disadvantages of static factories over constructors:

• Can't be subclassed.
• Poor naming conventions can make it hard to know what's going on.

Dagfinn Reiersøl wrote an interesting post about this:

I've never considered visibility restrictions important enough to be a major argument against those languages that have lacked them (PHP 4). So why would I be sceptical of public constructors? I got the idea after reading Joshua Kerievsky's book Refactoring to Patterns. One of his refactorings is called Replace Constructors with Creation Methods. In Java, unlike PHP, you can have multiple constructors that are distinguished only by the number and type of arguments. That may be practical sometimes, but as Kerievsky's example shows, it be more readable to have creation methods with different names instead. Which is what you have to anyway in PHP.

Read More: Public constructors considered harmful

I usually tell myself that if I come away from a conference having learnt one new thing, then it was a successful conference. If I come away having learnt one new thing per day, then it was a really excellent conference.

Well, I must admit that I wasn't expecting to get my 2-days' worth of new stuff at the first tutorial, but I did.

The idea behind Q-patterns (a.k.a. Questioning Patterns) is based on the idea behind Design patterns, i.e. REUSE.

In this case, the reuse is of Test Cases. Q-patterns provide:

• A means to communicate experience
• Aid in writing test cases
• A mechanism for test case reuse
• Aid in reviewing specifications and design

How do Q-patterns work?

Q-patterns are a method of questioning the scenario. They are a set of interrelated questions, grouped together, that relate to some aspect of user or software requirements, and provide various alternatives to arrive at a solution.

Basically, if you can ask a set of questions about a particular topic in context X, you can reuse these questions for the same topic in context Y.

Let's use an example: A combo box.

This small element of software has a number of attributes that are irrespective of the application that the combo box is used in. If a test engineer knows what types of questions to ask about a combo box in one application (in order to get a full understanding of how it works), s/he can reuse those questions with respect to a combo box in another application.

What sort of questions can you ask about a combo box?

Usage: Data Source:

• is the combo-box populated with values by default?
• what are the default values?
• where does the combo-box get its values from?
• what happens if the data source fails?

Usage: Data addition/deletion/modification

• How are new values added? Deleted?
• Can values be modified? How?
• Where are newly added values displayed? Beginning, end or based on some type of sort?
• Is it a single or multi select? If multiple, how is the select done?

User Interace:

• Is the combo box wide enough to display the widest element? If not, is scrolling possible?
• How is selection displayed?
• Does the box drop down to reveal all entries? Or only some? How do you scroll vertically?
• Can the box drop down and selections be made by using the keyboard? the mouse?

Internationalization

• Does the box accept and display etended ASCII characters?
• Does the box accept and display multi-byte characters?
• Does the box accept right-to-left scripts (e.g. Hebrew, Arabic)?

etc. etc. etc.

You get the picture.

These are a set of generic questions that need to have answers for any implementation of a combo box, and as such, they are reusable, and can be identified as part of the "Combo-box" Q-pattern.

Exploratory Testing and Q-Patterns

According to Vipul, one testing technique that can benefit in particular from Q-patterns is exploratory testing.

How come? Exploratory testing is based on a tester's experience. Using Q-patterns allows a tester to overcome the following challenges:

• exploratory testing is an individual's exercise
  • difficulty to pass on the knowledge gained
  • depends on the individual's skills
• exploratory testing involves designing tests and executing them at the same time
  • q-patterns can be created as you go along
  • q-patterns list various ways that things could work, and suggests various alternatives

Some of the Problems with Q-Patterns

There are a number of problems with Q-patterns. For example, you can easily end up with a huge set of questions (some of which may not be terribly useful) for a minute widget in the software. The chances are that for a large complex system, the list of questions will be unweildy, and there may be many duplicate questions in various Q-patterns.

Another possible issue is - who is going to write all these Q-patterns? It's all very well to identify a lot of generic bits and pieces, but is it worth writing the Q-patterns for them? A bit like reusable design and code - the first person designing or developing with reuse in mind doesn't actually benefit (and it's often more complicated to have reuse in mind from scratch), it's those who reuse the design, code or tests who benefit.

Vipul would like to have different companies work together to prepare a repository of Q-patterns, for all to reuse. Sort of like a "QWikipedia"  (DebiZ - I just coined that term!), but that just raises more issues: where would this repository reside? And what about each company's IP?

And last, but by no means least, how does one ensure that test engineers working with Q-patterns don't fall into the trap of stilted thinking?

To Summarize

I could go on quite a bit longer, but I don't intend to explain a 4-hour tutorial in a sinlge blog post!

Suffice to say that I came out of the tutorial with an understanding of Q-patterns, and some of their strengths and weaknesses.

If you have any thoughts about Q-patterns, as I've explained them, I'd be interested to hear your comments.

If you enjoyed this post, please consider subscribing to my RSS Feed, to keep up with all future updates, like the 2nd new thing I learnt from Vipul during this tutorial ...

I recently began working on my latest hobby project, a desktop application for viewing photographs using (hardware-accelerated) 3D rendering, implemented in Qt and OpenGL. It's been a while since using Qt, so I started small with a basic skeleton application, adding a menu bar, a toolbar and a status bar. I also implemented menu items to toggle the toolbar, the status bar and a full screen viewing mode.

The application doesn't do anything interesting yet, but even with this simple logic there are already several variables that could (and, in my opinion, should) be stored between sessions:

• Show/hide the toolbar?
• Show/hide the status bar?
• Show application in full screen, normal or maximized mode?
• Size and position of main window.

The Configuration Object

Most application frameworks (and some programming languages) provide utility classes for reading and writing persistent variables from and to configuration files or the system registry, like QSettings, wxConfig and java.util.Properties. The simplest way of providing persistence for application settings is to use these classes directly whenever needed. However, using them directly will often lead to duplication of code and possibly troublesome maintenance if access is spread across many modules and classes. Because of this—and other reasons I will mention later—I prefer to collect all variables and the code to read/write them in a separate configuration object.

For my simple Qt application, the code might look something like this:

[sourcecode language="cpp"]
class Config {
public:
bool maximized;
bool fullScreen;
bool showToolBar;
bool showStatusBar;
QString windowPos;

void read() {
QSettings settings("phex3d", "phex3d");
maximized = settings.value("maximized" , false).toBool());
fullScreen = settings.value("full_screen" , false).toBool());
showToolBar = settings.value("show_toolbar" , false).toBool());
showStatusBar = settings.value("show_statusbar", true ).toBool());
windowPos = settings.value("window_pos" , "" ).toString());
}

void write() {
QSettings settings("phex3d", "phex3d");
settings.setValue("maximized" , maximized);
settings.setValue("full_screen" , fullScreen);
settings.setValue("show_toolbar" , showToolBar);
settings.setValue("show_statusbar", showStatusBar);
settings.setValue("window_pos" , windowPos);
settings.sync();
}
};
[/sourcecode]

By making an instance of the configuration object available as a global variable (or a singleton, if that makes you sleep better), I can now easily reference persistent settings from anywhere in the application. For example, the event handler for toggling the toolbar could be something like this:

[sourcecode language="cpp"]
void Window::toggleToolbar(void)
{
bool visible = toolbar->isVisible();
config.showToolBar = !visible;
if (visible)
toolbar->hide();
else
toolbar->show();
}
[/sourcecode]

As long as I remember to call Config::read() on startup and Config::write() on exit, the settings will be saved and restored without any extra work needed.

Centralized Information

Although simple, the above solution will get somewhat messy if many variables are involved. For every new variable, extra code must be added to read() and write(). If we also think ahead a little, and take into account that these options will need to be exposed in a configuration dialog, allowing the user to change their values, we can recognize the need to associate some more information with each of them:

• The name of the option, typically used to identify it in a configuration file or the registry.
• A short description of what the option means and what part of the application is affected by changing it. This text will typically be used as a label for the check box, edit field or other widget used to change the variable in the configuration dialog.
• A more elaborate help text, suitable for use as a tool tip or in a separate help dialog.
• The default value, useful if you want to allow the user to reset something to "factory defaults".
• The data type of the option.

You may wonder why the variable names and data types are relevant in this context—they could stay hardcoded, like before—but if you consider more advanced configuration interfaces, like the Firefox about:config feature, they can be very useful.

To collect all information about an option in one place, you might define an Option class looking something like this:

[sourcecode language="cpp"]
class Option {
public:
enum OptionType { INT, STRING };

private:
QString name;
QString desc;
QString help;
int defInt;
QString defString;
OptionType type;
void *value;

public:
Option(int *var, const QString &name, int def, const QString desc = "", const QString &help = "" ) {
this->type = INT;
this->value = var;
this->name = name;
this->defInt = def;
this->desc = desc;
this->help = help;
}

Option(QString *var, const QString &name, const QString &def, const QString desc = "", const QString &help = "" ) {
this->type = STRING;
this->value = var;
this->name = name;
this->defString = def;
this->desc = desc;
this->help = help;
}

const QString &getName() { return name; }
const QString &getDescription() { return desc; }
const QString &getHelpText() { return help; }

OptionType getType(void) { return type; }
int getInt(void) { return *((int *) value); }
int getDefaultInt(void) { return defInt; }
const QString &getString(void) { return *((QString *) value); }
const QString &getDefaultString(void) { return defString; }

void setInt(int value) { *((int *) this->value) = value; }
void setString(const QString &value) { *((QString *) this->value) = value; }
};
[/sourcecode]

If you are wondering why the option value is stored as a pointer and not a local variable inside the Option class, I did this because I wanted them to reference the corresponding class variables in the configuration object, thus allowing me to continue accessing hem directly elsewhere in my application. It's kind of a hack, I know, but it works. If you don't like it, you can always use the get*() functions instead. Also, if you know a better solution, or how to solve the type info situation with templates, please share.

Now that we have all the information wee need about each option wrapped in a class, we can add a list of Option instances in our Config class to simplify and generalize the read() and write() implementations. The new Config class might look something like this:

[sourcecode language="cpp"]
class Config {
public:
int maximized;
int fullScreen;
int showToolBar;
int showStatusBar;
QString windowPos;
Option *_maximized;
Option *_fullScreen;
Option *_showToolBar;
Option *_showStatusBar;
Option *_windowPos;
QList option_list;

Config() {
settings = new QSettings("phex3d", "phex3d");

_maximized = addOption ("maximized" , &maximized , true );
_fullScreen = addOption ("fullscreen" , &fullScreen , false);
_showToolBar = addOption ("show_toolbar" , &showToolBar , false);
_showStatusBar = addOption ("show_statusbar", &showStatusBar, true );
_windowPos = addOption("window_pos" , &windowPos , "" );
}

~Config() {
for (QList::Iterator i = option_list.begin(); i < option_list.end(); i++)
delete *i;

delete settings;
}

template
Option *addOption(const QString &name, T *var, T value, const QString &desc = "", const QString &help = "" ) {
Option *option = new Option(var, name, value, desc, help);
option_list.append(option);
return option;
}

void read() {
for (QList::Iterator i = option_list.begin(); i < option_list.end(); i++) {
Option *option = *i;
if (option->getType() == Option::INT) {
QVariant value = settings->value(option->getName(), option->getDefaultInt());
option->setInt(value.toInt());
}
else {
QVariant value = settings->value(option->getName(), option->getDefaultString());
option->setString(value.toString());
}
}
}

void write() {
for (QList::Iterator i = option_list.begin(); i < option_list.end(); i++) {
Option *option = *i;
if (option->getType() == Option::INT)
settings->setValue(option->getName(), option->getInt());
else
settings->setValue(option->getName(), option->getString());
}
settings->sync();
}

private:
QSettings *settings;
};
[/sourcecode]

Outstanding Issues

The above solution works fine for my current needs in the application, but as we all know, needs change over time. I can already think of several outstanding issues that are not covered by this design, which might be needed in the future.

It would be useful to provide a list of valid values for each option. For example, if an integer option can only be between 1 and 100, this information should also be stored in the Option object. The same with text to display in a drop-down list or for auto-completing commonly used values as they are being entered in an edit field. If advanced validation or many different validation algorithms are used, this might be better solved by adding a reference to a validation object responsible for validating values for a given option.

As time passes, code is typically rewritten and programs restructured. This can eventually lead to the need, or simply the desire, to also rename options. For example, if the option window_pos describes the main window position, you may want to rename it to main.window_pos when more windows are added to the application. The issue can also arise when option names are automatically generated from class names (which is quite common for Java properties). When the name of the class changes, so will the option name. For this reason, it could be useful if the Option class was extended to provide a list of name aliases. The read() function could then be updated to use the value from an alias if found, but write() would only save it under the new name.

Another disadvantage of my simple design is that the Config class must know about all the options in the application, and therefore could get a tighter coupling with the various application modules than you might prefer. If your application supports custom extensions via plug-ins, it might be useful to implement functionality to add options to the Config object at run-time. For options that are added this way it will also be useful to provide a lookup function for retrieving the Option object based on name, i.e. by storing the objects in a map keyed by the option name as it was provided when the option was added.

I am likely to discover even more issues once I start implementing the configuration dialogs, but at least now I have an application that remembers where I left the window.

Please share your thoughts on this. Any feedback is appreciated.

The Pragmatic Programmers, Andy Hunt & Dave Thomas.

 // Command pattern -- Real World example

using System;

using System.Collections;

namespace CommandPattern
{

 // MainApp test application 

 class MainApp
 {
  static void Main()
  {
   // Create user and let her compute 
   User user = new User();

   user.Compute('+', 100);
   user.Compute('-', 50);
   user.Compute('*', 10);
   user.Compute('/', 2);

   // Undo 4 commands 
   user.Undo(4);

   // Redo 3 commands 
   user.Redo(3);

   // Wait for user 
   Console.Read();
  }
 }

 // "Command" 

 abstract class Command
 {
  public abstract void Execute();
  public abstract void UnExecute();
 }

 // "ConcreteCommand" 

 class CalculatorCommand : Command
 {
  char @operator;
  int operand;
  Calculator calculator;

  // Constructor 
  public CalculatorCommand(Calculator calculator,
  char @operator, int operand)
  {
   this.calculator = calculator;
   this.@operator  = @operator;
   this.operand    = operand;
  }

  public char Operator
  {
   set{ @operator = value; }
  }

  public int Operand
  {
   set{ operand = value; }
  }

  public override void Execute()
  {
   calculator.Operation(@operator, operand);
  }

  public override void UnExecute()
  {
   calculator.Operation(Undo(@operator), operand);
  }

  // Private helper function 
  private char Undo(char @operator)
  {
   char undo;
   switch(@operator)
   {
    case '+': undo = '-'; break;
    case '-': undo = '+'; break;
    case '*': undo = '/'; break;
    case '/': undo = '*'; break;
    default : undo = ' '; break;
   }
  return undo;
  }
 }

 // "Receiver" 

 class Calculator
 {
 private int curr = 0;

 public void Operation(char @operator, int operand)
 {
 switch(@operator)
 {
 case '+': curr += operand; break;
 case '-': curr -= operand; break;
 case '*': curr *= operand; break;
 case '/': curr /= operand; break;
 }
 Console.WriteLine(
 "Current value = {0,3} (following {1} {2})",
 curr, @operator, operand);
 }
 }

 // "Invoker" 

 class User
 {
 // Initializers 
 private Calculator calculator = new Calculator();
 private ArrayList commands = new ArrayList();

 private int current = 0;

 public void Redo(int levels)
 {
 Console.WriteLine("\n---- Redo {0} levels ", levels);
 // Perform redo operations 
 for (int i = 0; i < levels; i++)
 {
 if (current < commands.Count - 1)
 {
 Command command = commands[current++] as Command;
 command.Execute();
 }
 }
 }

 public void Undo(int levels)
 {
 Console.WriteLine("\n---- Undo {0} levels ", levels);
 // Perform undo operations 
 for (int i = 0; i < levels; i++)
 {
 if (current > 0)
 {
 Command command = commands[--current] as Command;
 command.UnExecute();
 }
 }
 }

 public void Compute(char @operator, int operand)
 {
 // Create command operation and execute it 
 Command command = new CalculatorCommand(
 calculator, @operator, operand);
 command.Execute();

 // Add command to undo list 
 commands.Add(command);
 current++;
 }
 }
}

Olhando meus códigos, quantas vezes usei os padrões singleton, command e interpreter sem ter a mínima idéia do que eram. O conhecimento deles teria me poupado muito tempo. Quem me despertou pra esta realidade foi o excelente livro Php Profissional dos autores Alexandre Altair e Maurício Nascimento.

Mas o motivo desta rapidinha é a descoberta de um site muito bom sobre este assunto, o Design Patterns . O site , em inglês, agrupa por tipo e descreve cada padrão de forma sucinta e didática. Os exemplos fornecidos em diversas linguagens, incluindo o Object Pascal e PHP, são práticos e úteis.

Faça uma visita e aproveite sua dose de padrões de projeto. Apenas cuidado pra não pegar a febre e sair aplicando padrões num programa Alô Mundo. Até a próxima!

Design Patterns

public sealed SingletonClass
{
  private SingletonClass() {}

  public static readonly SingletonClass Instance = new SingletonClass();
}

Wiele osób uważa, że stosowanie singletonów jest przejawem złej architektury gdyż wprowadzają one ścisłe powiązania między poszczególnymi klasami, co z kolei utrudnia pisanie testów. W zupełności się z tym zgadzam, jednak, jeśli mam wybierać pomiędzy zmiennymi globalnymi to z dwojga złego wolę wykorzystać singleton. Przynajmniej pomoże pogrupować 'zmienne' w jakąś logiczną strukturę.

Poza tym nie tak naprawdę singleton'ów, nie da się całkowicie uniknąć, z dwóch powodów:

• Pomimo tego, co niektórzy twierdzą, istnieją sytuacje wymagające ich zastosowania jak na przykład interakcja z hardwarem.
• Wydajność - i nie chodzi mi tu o aplikacje serwerowe itp. - ale te mniejsze pracujące przykładowo na urządzeniach przenośnych.

Some time we produce too redundant code. For example implementing Data Access Objects and writing the basic functionality code in each DAO (when using different DAO for each entity). By using Layer SuperType we can eliminate such problem.

For example in one of my (Hibernate and Struts based) project, I am using the Layer SuperType. I have written a class named AbstractDAO (which is basically super layer of Layer SuperType) as follow:

public class AbstractDao {

protected static Session session;
protected static Transaction tx;

 public AbstractDao() {
     HibernateSessionFactory.buildIfNeeded();
}

protected void save(Object obj) {
 try {

     startOperation();
     session.save(obj);
     tx.commit();

     } catch (HibernateException e) {
       handleException(e);

     } finally {
       HibernateSessionFactory.closeSession();
     }
} 

public void saveOrUpdate(Object obj) {
 try {

     startOperation();
     session.saveOrUpdate(obj);
     tx.commit();

     } catch (HibernateException e) {
       handleException(e);

     } finally {
       HibernateSessionFactory.closeSession();
     }
}

and other methods that need to be come under Super Layer.

Now code of DAOs for each entity is extrememly minimized, and you dont need to make explicit type casts while calling DAO's methods. And the most important thing is, you don't need to write the exception handing logic in DAOs which is very time/space taking activity.

Now I show you one DAO which uses the Layer SuperType.

public class WidgetDAO  extends AbstractDao{

public WidgetDAO() {
     super(); 
}

public Widget getWidget(Integer id){

 Widget widget = new Widget();
 widget = (Widget)super.objQuery("from Widget w where w.id=" + id);
 return widget;

}

public void addorUpdateWidget(Widget widget){

  super.saveOrUpdate(widget);

}
}

Now i can get a widget using:

Widget wgt = new WidgetDAO().getWidget(1); // here 1 is Widget ID

You see how Layer SuperTypes makes the application code simple, clean, and minimized.

Interview with Cliff Hall, creator of PureMVC.

The Manifold Project.

Discussion of Cairngorm and PureMVC as patterns of GUI architecture.

PureMVC Startup Manager.

PureMVC Asset Loader example.

the Observer design pattern define a one-to-many relationship between objects that when an object status changes the other dependent objects be notified.

the idea is : there is an object that has a peace of information, many other objects interested in knowing when its state changes.

the way to handle this is creating a way to allow dependent objects to register to be notified when the status changes. here is an imagination of how you can model this situation:

From the diagram you can see that we created to interfaces one for the subject object which will contains the information or status other objects needed to be aware about. the Subject interface has 3 methods registerObserver, deregisterObserver and notifyObservers.

registerObserver(): takes an Observer object as a argument and add this object to an internal arraylist or whatever you choose to keep all registered observers on it.

deregisterObserver(): takes an Observer object as a argument and and remove this object from the observers arraylist.

notifyObservers(): call the update() method on all observers exists on the observers arraylist and send the new status(s) as arguments.

The Observer Interface contains one method update()

update(): this method takes the status or information it interested in as argument(s).

so in pref. an subject object has information some observer objects interested in, so the observer objects register themselves on the subject object by calling the register method.

when the data in the subject object changed the notifyObservers method call and it send the new information by calling update method in all registered observers.

when an observer object decided to stop receiving updates it deregister himself from the subject object by calling deregister method() on the subject object.

However, after finishing my lsat project at Pitney Bowes, I now have first hand experience of how sweet your code becomes when you follow principles like IoC, AOP, Transaction Management (using attributes and AOP). Also this is the first time, I've used interfaces so heavily.

Have a lookat this DPPConnector presentation and decide for yourself if this code is sweet or not.

I usually tell myself that if I come away from a conference having learnt one new thing, then it was a successful conference. If I come away having learnt one new thing per day, then it was a really excellent conference.

Well, I must admit that I wasn't expecting to get my 2-days' worth of new stuff at the first tutorial, but I did.

The idea behind Q-patterns (a.k.a. Questioning Patterns) is based on the idea behind Design patterns, i.e. REUSE.

In this case, the reuse is of Test Cases. Q-patterns provide:

• A means to communicate experience
• Aid in writing test cases
• A mechanism for test case reuse
• Aid in reviewing specifications and design

How do Q-patterns work?

Q-patterns are a method of questioning the scenario. They are a set of interrelated questions, grouped together, that relate to some aspect of user or software requirements, and provide various alternatives to arrive at a solution.

Basically, if you can ask a set of questions about a particular topic in context X, you can reuse these questions for the same topic in context Y.

Let's use an example: A combo box.

This small element of software has a number of attributes that are irrespective of the application that the combo box is used in. If a test engineer knows what types of questions to ask about a combo box in one application (in order to get a full understanding of how it works), s/he can reuse those questions with respect to a combo box in another application.

What sort of questions can you ask about a combo box?

Usage: Data Source:

• is the combo-box populated with values by default?
• what are the default values?
• where does the combo-box get its values from?
• what happens if the data source fails?

Usage: Data addition/deletion/modification

• How are new values added? Deleted?
• Can values be modified? How?
• Where are newly added values displayed? Beginning, end or based on some type of sort?
• Is it a single or multi select? If multiple, how is the select done?

User Interace:

• Is the combo box wide enough to display the widest element? If not, is scrolling possible?
• How is selection displayed?
• Does the box drop down to reveal all entries? Or only some? How do you scroll vertically?
• Can the box drop down and selections be made by using the keyboard? the mouse?

Internationalization

• Does the box accept and display etended ASCII characters?
• Does the box accept and display multi-byte characters?
• Does the box accept right-to-left scripts (e.g. Hebrew, Arabic)?

etc. etc. etc.

You get the picture.

These are a set of generic questions that need to have answers for any implementation of a combo box, and as such, they are reusable, and can be identified as part of the "Combo-box" Q-pattern.

Exploratory Testing and Q-Patterns

According to Vipul, one testing technique that can benefit in particular from Q-patterns is exploratory testing.

How come? Exploratory testing is based on a tester's experience. Using Q-patterns allows a tester to overcome the following challenges:

• exploratory testing is an individual's exercise
  • difficulty to pass on the knowledge gained
  • depends on the individual's skills
• exploratory testing involves designing tests and executing them at the same time
  • q-patterns can be created as you go along
  • q-patterns list various ways that things could work, and suggests various alternatives

Some of the Problems with Q-Patterns

There are a number of problems with Q-patterns. For example, you can easily end up with a huge set of questions (some of which may not be terribly useful) for a minute widget in the software. The chances are that for a large complex system, the list of questions will be unweildy, and there may be many duplicate questions in various Q-patterns.

Another possible issue is - who is going to write all these Q-patterns? It's all very well to identify a lot of generic bits and pieces, but is it worth writing the Q-patterns for them? A bit like reusable design and code - the first person designing or developing with reuse in mind doesn't actually benefit (and it's often more complicated to have reuse in mind from scratch), it's those who reuse the design, code or tests who benefit.

Vipul would like to have different companies work together to prepare a repository of Q-patterns, for all to reuse. Sort of like a "QWikipedia"  (DebiZ - I just coined that term!), but that just raises more issues: where would this repository reside? And what about each company's IP?

And last, but by no means least, how does one ensure that test engineers working with Q-patterns don't fall into the trap of stilted thinking?

To Summarize

I could go on quite a bit longer, but I don't intend to explain a 4-hour tutorial in a sinlge blog post!

Suffice to say that I came out of the tutorial with an understanding of Q-patterns, and some of their strengths and weaknesses.

If you have any thoughts about Q-patterns, as I've explained them, I'd be interested to hear your comments.

If you enjoyed this post, please consider subscribing to my RSS Feed, to keep up with all future updates, like the 2nd new thing I learnt from Vipul during this tutorial ...

Bookmark me at:

source : http://jt.dev.java.net

El patrón comando encapsula una llamada como un objeto,por lo que nos permite parametrizar distintos objetos con diferentes llamadas. Este patrón nos sirve de utilidad cuando necesitamos desacoplar el objeto que hace un determinado requerimiento de los objetos que saben como realizar los dichos requerimientos

Descripcion

• Cliente : Es el responsable de Crear un comando concreto (de hacer el new) y de establecer su Receptor.
• Receptor : El receptor es el que sabe que trabajo debe realizarse para que el requerimiento pueda ser realizado satisfactoriamente.
• Interface de Comando : Define la Interface comun para todos los comandos homegeneizando la forma de invocar los distintos comandos que puede haber un sistema
• Comando Concreto : Define el lazo entre las acciones que debe realizar el receptor para lograr un determinado requerimiento y el solicitante que pide que un determinado sea ejecutado mediante la interface de Comando
• Solicitante : El solicitante tiene acceso a un determinado comando y hace el requerimiento para que este sea realizado llamando al metodo Ejecutar() del mismo

Ejemplo

Algunas Máximas de Programación Orientada a Patrones

• Dependa de Clases Abstractas no de Clases Concretas
• Programe Orientado a Funcionalidades (Interfaces) no a implementaciones
• Encapsule lo que varia
• Las Clases deberían estar Abiertas a Extension pero cerradas a modificaciones

Damon pointed out that the Parallel Extensions library contains a Future<T> class, so I started looking around for examples and explanations of how they work, what the syntax is like, and I ran across a frightening example implementing the asynchronous programming model with Future<T>, as well as going in the other direction, wrapping an APM implementation with Future<T>.  Other articles give pretty good explanations but trivial examples.  From what I gathered briefly, the ContinueWith method for specifying the next step of calculation to process doesn’t seem to provide an intuitive way to indicate that several calculations may be depending upon the current one (unless it can be called multiple times?).  Using ContinueWith, you’re always specifying forward the calculation task that depends on the current future object.  It also surprised me a little that Future inherits from Task, because my understanding of a future is that it’s primarily defined as a value-holding object.  But considering that a future really holds an expression that needs to be calculated, making Future a Task doesn’t seem so odd.

So I decided to implement my own Future<T> class before looking at the parallel extensions library too deeply.  I didn’t want to prejudice my solution, because I wanted to make an exercise of it and see what I would naturally come up with.

Though I tried avoiding prejudice, I still wound up characterizing it in my head as an task, and thought that a future would simply be a pair of Action and Reaction methods (both of the Action delegate type).  The Action would execute and could do whatever it liked, including evaluate some expression and store it in a variable.  If the Action completed, the Reaction method (a continuation) would run, and these could be specified using lambdas.  Because I was storing the results in a local variable (result), swallowed up and made accessible with a closure, I didn’t see a need for a Value property in the future and therefore no need to make the type generic.  Ultimately I thought it silly to have a Reaction method, since anything you needed to happen sequentially after a successful Action, you could simply store at the end of the Action method itself.

FutureTask task = new FutureTask(
    () => result = CalculatePi(10),
    () => new FutureTask(
        () => result += "...",
        () => Console.WriteLine(result),
        ex2 => Console.WriteLine("ex2: " + ex2.Message)),
    ex1 => Console.WriteLine("ex1: " + ex1.Message));

The syntax is what I was most concerned with, and as I started playing around with nesting of futures to compose my calculation, I started to feel like I was onto something.  After all, it was almost starting to resemble some of the F# code I’ve been looking at, and I took that style of functional composition to be a good sign.  As you can see from the code above, I also include a constructor parameter of type Action<Exception> for compensation logic to run in the event that the original action fails.  (The result variable is a string, CalculatePi returns a string, and so the concatenation of the ellipsis really does make sense here.)

The problem that started nagging me was the thought that a composite computation of future objects might not be able to be defined all in one statement like this, not building the dependency tree from the bottom up.  You can really only define the most basic factors (the leaf nodes of a dependency tree) at the beginning this way, and then the expressions that depend directly upon those leaf nodes, etc.  What if you have 50 different starting future values, and you can only proceed with the next step in the calculation once 5 of those specific futures have completed evaluation?  How would you express those dependencies with this approach?

That’s when I started to think about futures as top-down hierarchical data container objects, instead of tasks that have pointers to some next task in a sequence.  I created a Future<T> class whose constructor takes an optional name (to aid debugging), a method of type Func<T> (which is a simple expression, supplied as a lambda in my examples), and finally an optional params list of other Future<T> objects on which that future value depends.

The first two futures in the code below start calculating pi (3.1415926535) and omega (which I made up to be a string of 9s).  They have no dependencies, so they can start calculating right away.  The paren future has two dependencies, supplied as two parameters at the end of the argument list: pi and omega.  You can see that the values pi.Value and omega.Value are used in the expression, which will simply surround the concatenated string value with parentheses and spaces.

var pi = new Future<string>("pi", () => CalculatePi(10));
var omega = new Future<string>("omega", () => CalculateOmega());

var paren = new Future<string>("parenthesize", () => Parenthesize(pi.Value + " < " + omega.Value), pi, omega);

var result = new Future<string>("bracket", () => Bracket(paren.Value), paren);

Finally, the result future has a dependency on the paren future.  This surrounds the result of paren.Value with brackets and spaces.  Because the operations here are trivial, I’ve added Thread.Sleep statements to all of these methods to simulate more computationally expensive work.

The program starts calculating pi and omega concurrently, and then immediately builds the paren future, which because of its dependencies waits for completion of the pi and omega futures.  But it doesn’t block the thread.  Execution continues immediately to build the result future, and then moves on to the next part of the program.  When each part of the expression, each future, completes, it will set a Complete boolean property to true and invoke a Completed event.  Any attempt to access the Value property of one of these futures will block the thread until it (and all of the futures it depends on) have completed evaluation.

Furthermore, if an exception occurs, all of the futures that depend on it will no longer attempt to evaluate, and the exceptions will be thrown as part of an AggregateException when accessing the Value property.  This AggregateException contains all of the individual exceptions that were thrown as part of evaluating each future expression.  If both pi and omega fail, result should be able to hand me a list of all Exceptions below it in the tree structure that automatically gets formed.

There are two bits of code I added as icing on this cake.  The first is the use of the implicit operator to convert a variable of type Future<T> to type T.  In other words, if you have a Future<string> called result, you can now pass result into methods where a string parameter is expected, etc.  In the code listing at the end of the article, you’ll notice that I reference pi and omega instead of pi.Value and omega.Value (as in the code snippet above).

public static implicit operator T(Future<T> Future)
{
    return Future.Value;
}

The other helpful bit is an override of ToString, which allows you to hover over a future variable in debug mode and see its name (if you named it), whether it’s Complete or Incomplete, and any errors encountered during evaluation.

public override string ToString()
{
    return Name + ", " + (Complete ? "Complete" : "Incomplete") + (Error != null ? "Error=" + Error.Message : string.Empty);
}

What I’d really like to do is have the ability to construct this composite expression in a hierarchical form in the language, with a functionally composed syntax, replacing any parameter T with a Future<T>, something like this:

var result = new Future<string>("bracket", () => Bracket(
    new Future<string>("parenthesize", () => Parenthesize(
        new Future<string>("pi", () => CalculatePi(10))
        + " < " +
        new Future<string>("omega", () => CalculateOmega())
    ))
));

The Bracket and Parenthesize methods both require a string, but I give them an object that will at some point (“in the future”) evaluate to a string.  Another term used for future is promise, although there is a distinction in some languages that support both, but you can think in terms of giving those methods the promise that they’ll get a string later, at which time they can proceed with their own evaluation.  This effectively creates lazy evaluation, sometimes referred to as normal-order evaluation.

There are a few problems with this code, however.  First of all, though it’s composed functionally from the top down and returns the correct answer, it takes too long to do it: about 8 seconds instead of 4.  That means it’s processing all of the steps sequentially.  This happens because the future objects we’re handing to the Parenthesize and Bracket methods have to be converted from Future<string> to string before they can be evaluated in the expression, and doing that activates the implicit operator, which executes the Value property getter.  This completely destroys the asynchronous behavior we’re going for, by insisting on resolving it immediately with the wait built-into the Value property.  The string concatenation expression evaluates sequentially one piece at a time, and when that’s done, the next level up evaluates, and so on.

The solution is to declare our futures as factors we depend on at each level, which start them executing right away due to C#’s order of evaluation, and declare the operations we want to perform in terms of those predefined futures.  After a few hours of rearranging definitions, declaration order, and experimenting with many other details (including a brief foray into being more indirect with Func<Future<T>>), this is the working code I came up with:

Future<string> FuturePi = null, FutureOmega = null, FutureConcat = null, FutureParen = null;

var result = new Future<string>(
    () => Bracket(FutureParen),
    (FutureParen = new Future<string>(
        () => Parenthesize(FutureConcat),
        (FutureConcat = new Future<String>(
            () => FuturePi + " < " + FutureOmega,
            (FuturePi = new Future<string>(() => CalculatePi(10))),
            (FutureOmega = new Future<string>(() => CalculateOmega()))
        ))
    ))
);

In F# and other more functional languages, I imagine we could use let statements to define and assign these variables as part of the overall expression, instead of having to define the variables in a separate statement as shown here.

The Future<T> class I wrote works fairly well for exploration and study of futures and the possible syntax to define them and access their values, and I’ll share it so that you can experiment with it if you like, but understand that this is (even more so than usual) not production ready code.  I’m making some very naive assumptions, not taking advantage of any task managers or thread pools, there is no intelligent scheduling going on, and I haven’t tested this in any real world applications.  With that disclaimer out of the way, here it is, complete with the consuming test code.

using System;
using System.Collections.Generic;
using System.Threading;
using System.Linq;

namespace FutureExpressionExample
{
    class Program
    {
        static void Main(string[] args)
        {
            DateTime StartTime = DateTime.Now;

            Future<string> FuturePi = null, FutureOmega = null, FutureConcat = null, FutureParen = null;

            var result = new Future<string>("bracket",
                () => Bracket(FutureParen),
                (FutureParen = new Future<string>("parenthesize",
                    () => Parenthesize(FutureConcat),
                    (FutureConcat = new Future<String>("concat",
                        () => FuturePi + " < " + FutureOmega,
                        (FuturePi = new Future<string>("pi", () => CalculatePi(10))),
                        (FutureOmega = new Future<string>("omega", () => CalculateOmega()))
                    ))
                ))
            );

            /* Alternative

            // first group of expressions evaluating in parallel
            var pi = new Future<string>("pi", () => CalculatePi(10));
            var omega = new Future<string>("omega", () => CalculateOmega());

            // a single future expression dependent on all of the futures in the first group
            var paren = new Future<string>("parenthesize", () => Parenthesize(pi + " < " + omega), pi, omega);

            // another single future expression dependent on the paren future
            var result = new Future<string>("bracket", () => Bracket(paren), paren);

            */

            Console.WriteLine("Do other stuff while calculation occurs...");

            try
            {
                Console.WriteLine("\n" + result);
            }
            catch (AggregateException ex)
            {
                Console.WriteLine("\n" + ex.Message);
            }

            TimeSpan ts = DateTime.Now - StartTime;
            Console.WriteLine("\n" + ts.TotalSeconds.ToString() + " seconds");

            Console.ReadKey();
        }

        static string CalculatePi(int NumberDigits)
        {
            //throw new ApplicationException("Failed to calculate Pi");
            Thread.Sleep(3000);
            return "3.1415926535";
        }

        static string CalculateOmega()
        {
            //throw new ApplicationException("Failed to calculate Omega");
            Thread.Sleep(3000);
            return "999999999999999";
        }

        static string Parenthesize(string Text)
        {
            Thread.Sleep(500);
            return "( " + Text + " )";
        }

        static string Bracket(string Text)
        {
            Thread.Sleep(500);
            return "[ " + Text + " ]";
        }
    }

    public class Future<T> : IDisposable
    {
        public string Name { get; set; }
        public bool Complete { get; protected set; }
        public Exception Error { get; protected set; }

        protected Func<T> Expression { get; set; }

        protected List<Future<T>> Factors;
        protected List<Future<T>> FactorsCompleted;
        protected List<Future<T>> FactorsFailed;

        public event Action<Future<T>> Completed;
        protected void OnCompleted()
        {
            Complete = true;

            if (Completed != null)
                Completed(this);
        }

        private T _Value;
        public T Value
        {
            get
            {
                // block until complete
                while (!Complete)
                {
                    Thread.Sleep(1);
                }

                if (Exceptions.Count > 0)
                    throw new AggregateException(Exceptions);

                return _Value;
            }
            private set { _Value = value; }
        }

        public List<Exception> Exceptions
        {
            get
            {
                var list = new List<Exception>();

                foreach (Future<T> Factor in Factors)
                {
                    list.AddRange(Factor.Exceptions);
                }

                if (Error != null)
                    list.Add(Error);

                return list;
            }
        }

        public static implicit operator T(Future<T> Future)
        {
            return Future.Value;
        }

        // naming a Future is optional
        public Future(Func<T> Expression, params Future<T>[] Factors) : this("<not named>", Expression, Factors) { }

        public Future(string Name, Func<T> Expression, params Future<T>[] Factors)
        {
            this.Name = Name;
            this.Expression = Expression;
            this.Factors = new List<Future<T>>(Factors);

            FactorsCompleted = new List<Future<T>>();
            FactorsFailed = new List<Future<T>>();

            foreach (Future<T> Factor in this.Factors)
            {
                if (Factor.Complete)
                    FactorsCompleted.Add(Factor);
                else
                    Factor.Completed += new Action<Future<T>>(Factor_Completed);
            }

            // there may not be any factors, or they may all be complete
            if (FactorsCompleted.Count == this.Factors.Count)
                Expression.BeginInvoke(ReceiveCallback, null);
        }

        private void Factor_Completed(Future<T> Factor)
        {
            if (!FactorsCompleted.Contains(Factor))
                FactorsCompleted.Add(Factor);

            if (Factor.Error != null && !FactorsFailed.Contains(Factor))
                FactorsFailed.Add(Factor);

            Factor.Completed -= new Action<Future<T>>(Factor_Completed);

            if (Exceptions.Count > 0)
            {
                Dispose();
                OnCompleted();
                return;
            }

            if (FactorsCompleted.Count == Factors.Count)
                Expression.BeginInvoke(ReceiveCallback, null);
        }

        private void ReceiveCallback(IAsyncResult AsyncResult)
        {
            try
            {
                Value = Expression.EndInvoke(AsyncResult);
            }
            catch (Exception ex)
            {
                Error = ex;
            }

            Dispose();

            // computation is completed, regardless of whether it succeeded or failed
            OnCompleted();
        }

        public void Dispose()
        {
            foreach (Future<T> Factor in Factors)
            {
                Factor.Completed -= new Action<Future<T>>(Factor_Completed);
            }
        }

        // helpful for debugging
        public override string ToString()
        {
            return Name + ", " + (Complete ? "Complete" : "Incomplete") + (Error != null ? ", Error=" + Error.Message : string.Empty);
        }
    }

    public class AggregateException : Exception
    {
        public List<Exception> Exceptions;

        public AggregateException(IEnumerable<Exception> Exceptions)
        {
            this.Exceptions = new List<Exception>(Exceptions);
        }

        public override string Message
        {
            get
            {
                string message = string.Empty;
                foreach (Exception ex in Exceptions)
                {
                    message += ex.Message + "\n";
                }
                return message;
            }
        }
    }
}

To briefly re-cap and pad out the initial requirement, the idea is to build a small app where a person (and their address details) can be stored. There will be a minimum requirement that a person must have a full name (forename and surname) and an address for that person to be “published” to a list of people on the system. Draft person records can be created with incomplete details, and stored until such a time when they can be completed and published.

Please keep in mind as you read this that this will be this first time I’ve *attempted to* use TDD in anger, so please feel free to confront me about any questionable decisions I make, and I’ll try and make time to adjust the app/discuss the issues further!

Right, without further ado I’ll begin!

The first unit test

In attempting to follow the TDD mantra, the first step is to code out my first test. I figure I’d start with trying to return a list of people (or Persons) and since I know from my last post I want program against an abstraction, I know this list will be of type IPerson. Since I also know I wish to filter this list, I want my return type to be IQueryable. So this leaves me with:

[TestMethod]
public void Repository_ShouldReturn_Persons_AsQueryable()
{
    IDataContext rep = new InMemoryRepository();
    var query = from persons in rep.Repository<IPerson>()
                select persons;

    Assert.IsInstanceOfType(query, typeof(IQueryable<IPerson>));
    Assert.IsTrue(query.Count() > 0);
}

Of course since the none of these objects exist yet, the code will not build. With a little help from Resharper it’s easy to create some empty interfaces for IDataContext and IPerson and a basic implementation of InMemoryRepository to enable this code to build. These interfaces and classes now sit in the test project, within the InMemoryRepositoryTests code file and are marked as internal. At this point, this doesn’t matter. There’ll be a time to sort this out later in the process.

Now at this point, I run my first test, and of course, it fails – my repository method throws a NotImplementedException. At this point I really want to cheat a little since I already have an implementation I can use for this method that I’d like to use, but I know I would probably be burnt at the stake for such a blatant abuse of TDD, so I grit my teeth and continue. The TDD process tells me I should be adding the simplest implementation possible to make the test pass, so I write:

public IQueryable<T> Repository<T>()
{
    IList<T> items = new List<T>();

    return items.AsQueryable();
}

…and it fails again. This time with the message "Assert.IsTrue failed." – of course, there is no data being returned. Duh! This is easy to fix, I know I need to return a list of IQueryable<Person> so I add the following lines just above the return statement:

IPerson person = new Person();
items.Add((T)person);

This time, I run my test, and watch it pass!

Now I’m allowed to refactor. This is once again where Resharper comes in really handy; a few Alt+Enters and I’ve separated my objects and interfaces into separate files. I can then move IPerson and Person into a separate project called business objects (for want of a better name) and move IDataContext and InMemoryRepository into their own project (aptly named DataAccess). A few more tweaks are needed (like changing the protection level of the classes from internal to public, and altering namespaces) and I hit my next point requiring consideration – since I am making reference to the person object in the InMemoryRepository class, there is a one-way project dependency from my DataAccess project, to my BusinessObjects project and it appears that the dependency is avoidable. Since I want to avoid this dependency, I refactor the implementation to allow items to be inserted to an internally maintained list of objects:

private readonly List<object> _inMemoryDataStore = new List<object>();

public IQueryable<T> Repository<T>()
{
    var query = from objects in _inMemoryDataStore
                where typeof(T).IsAssignableFrom(objects.GetType())
                select objects; 

    return query.Select(o => (T)o).AsQueryable();
}

public void Insert<T>(T item)
{
    _inMemoryDataStore.Add(item);
}

I then add the Insert definition to my IDataContext so I can initialise the test with some data. Now my code builds again, I can now run my test again watch it pass!

Phew! That’s all I’m going to cover in this post. In later posts I will try to cover off returning Address details related to a person, implementing repositories that persist data to a database, implementing a “draft” repository, and switching between the pluggable dependencies.

In the end, I answered his question by pointing him to the blog that I had read. This blog discusses the Repository Pattern and goes on to propose a super-flexible repository interface that allows different implementations of the repository to be swapped out – the primary goal being the ability to run unit tests in isolation (without hitting the database). The blog also emphasises that the power of an abstraction is it’s transparent plugability; the ability to swap in a “draft repository” is now made possible and changes made in draft can be persisted to a different storage location than the live data.

It’s not a big leap from here to see how different implementations of an IPerson interface could have differing validation logic depending on the context (draft or published). By programming against the abstraction of the repository interface, and against abstractions of the returned types, we can (with minimal effort) swap out different implementations to provide the required functionality. I’d quite like to have a go at implementing this technique myself to see what I can come up with. Perhaps in future posts I’ll explore this technique further.

First we'll set up our start time and the thread.  I use the System.Threading.Timer to ensure that we're using a non-UI thread.

StartTime = DateTime.Now;

Timer = new System.Threading.Timer(new TimerCallback(Timer_Tick));
Timer.Change(0, 1000);

Here's the event handler that calculates the elapsed time and calls Invoke, as well as the method we're invoking, which will run on the UI thread, where it can safely update the lblElapsedTime label control.

private void Timer_Tick(object state)
{
    TimeSpan ts = DateTime.Now - StartTime;
    Invoke(new StringDelegate(DisplayText), ts.TotalSeconds.ToString());
}

private void DisplayText(string Text)
{
    lblElapsedTime.Text = Text;
}

In order to make this work, we need the event handler, a separate method to run in the UI thread, and also a delegate that matches the invoked method.

public delegate void StringDelegate(string Text);

This is a lot of moving parts for such a small piece of functionality.  To make matters worse, you may need to repeat this pattern many times, depending on the controls (or combinations thereof) that you need to update.  In a modern multi-threaded application, your class can become littered with these invocations, handlers, and delegates.

What I'd really like to do is call Invoke and pass in an anonymous method (in lambda form).  Unfortunately, Invoke takes a Delegate parameter, which is an abstract type.  This forces you to instantiate a concrete delegate type.  So while we eliminate our need for a separate method, we're still dependent on our delegate type.

private void Timer_Tick(object state)
{
    TimeSpan ts = DateTime.Now - StartTime;
    Invoke(new StringDelegate(s => lblElapsedTime.Text = s), ts.TotalSeconds.ToString());
}

Or are we?  By using the Action (or MethodInvoker) delegate for all of these invocations, and relying on C# and its support for closures, we can make a reference to the TimeSpan variable from within the anonymous method body, like this:

private void Timer_Tick(object state)
{
    TimeSpan ts = DateTime.Now - StartTime;
    Invoke(new Action(() => lblElapsedTime.Text = ts.TotalSeconds.ToString()));
}

Here it's contained within a single method, and no additional delegates will be necessary to make this work.  That's pretty nice!  (A similar approach is taken here.)  But it's still not quite as slick and intuitive as I'd like.  By creating an extension method, adding another overload of Invoke to the Control class, we can allow Invoke to assume a concrete Action delegate class, and write code like this:

private void Timer_Tick(object state)
{
    TimeSpan ts = DateTime.Now - StartTime;
    this.Invoke(() => lblElapsedTime.Text = ts.TotalSeconds.ToString());
}

Now that's clean.  Just call Invoke, and pass in the lambda to execute.  Or several statements in a code block if you like.  It's very succinct.  The only part that bothers me is the this keyword that's required.  Extension methods don't register in Intellisense, nor do they compile successfully, if they're used without a variable, this, base, or something else with a dot after them.  If we're really going to push the illusion of extending a class, I think we need to go all the way and make it work without having to explicitly type this.  But it is what it is for now; hopefully this will be fixed in the next version of C# (along with adding support for extension properties, events, and operators).

That being said, here is the extension method to make this work:

public static void Invoke(this Control Control, Action Action)
{
    Control.Invoke(Action);
}

It couldn't be simpler (thanks to a little help from Mads Torgersen)!  I'll include the finished program for those of you who want to run it to see and experiment; you'll just need to create the Program.cs with the startup code yourself.  Create a new Windows Forms app and use what's there, renaming the form listed in Application.Run to match this one.

using System;
using System.Drawing;
using System.Windows.Forms;
using System.Threading;

namespace ControlInvokeLambda
{
    public partial class frmTestInvokeLambda : Form
    {
        private Button btnExit;
        private Label lblElapsedTime;

        // make sure we're using the Threading Timer for our example, which runs on a non-UI thread
        private System.Threading.Timer Timer;

        private DateTime StartTime;

        public frmTestInvokeLambda()
        {
            // initialize controls

            btnExit = new Button();
            btnExit.Location = new Point(88, 80);
            btnExit.Name = "btnExit";
            btnExit.Size = new Size(118, 26);
            btnExit.TabIndex = 0;
            btnExit.Text = "Exit";
            btnExit.UseVisualStyleBackColor = true;
            btnExit.Click += new EventHandler(this.btnExit_Click);

            lblElapsedTime = new Label();
            lblElapsedTime.AutoSize = true;
            lblElapsedTime.Location = new Point(140, 36);
            lblElapsedTime.Name = "lblElapsedTime";
            lblElapsedTime.Size = new Size(13, 13);
            lblElapsedTime.TabIndex = 1;
            lblElapsedTime.Text = "0";

            AutoScaleDimensions = new SizeF(6F, 13F);
            AutoScaleMode = AutoScaleMode.Font;
            ClientSize = new Size(292, 136);
            Controls.Add(lblElapsedTime);
            Controls.Add(btnExit);
            Name = "frmTestInvokeLambda";
            Text = "Invoke Lambda";
            PerformLayout();

            // remember start time and startup timer

            StartTime = DateTime.Now;

            Timer = new System.Threading.Timer(new TimerCallback(Timer_Tick));
            Timer.Change(0, 1000);
        }

        private void btnExit_Click(object sender, EventArgs e)
        {
            Timer.Change(Timeout.Infinite, Timeout.Infinite);
            Application.Exit();
        }

        private void Timer_Tick(object state)
        {
            TimeSpan ts = DateTime.Now - StartTime;
            this.Invoke(() => lblElapsedTime.Text = ts.TotalSeconds.ToString());
        }
    }

    public static class ControlExtensions
    {
        public static void Invoke(this Control Control, Action Action)
        {
            Control.Invoke(Action);
        }
    }
}

In this newest version I have added AOP support to cut down on cross cutting code and also the ability to delete staff members from the GridView, most of the time spent was fighting against the asp.net controls (suprise, surprise) such as the GridView and the ObjectDataSource, I'm not sure what the guy(s) who created the ObjectDataSource object was smoking at the time but it must have been stronger than just tobacco :-)

My next release I want to demonstrate adding some service support showing how we can re-use existing code so they become little more than a remote facade (in theory!).

Here is the thread-spawning pattern I've used, and have seen used, countless times:

protected override void OnStart()
{
    Thread t = new Thread(new ThreadStart(Go));
    t.Name = "PrefetchLookupData";
    t.IsBackground = true;
    t.Priority = ThreadPriority.AboveNormal;
    t.Start();
}

private void Go()
{
    var c1 = LookupListDA.CustomerTypes;
    var c2 = LookupListDA.SalesOrderStates;
    var c3 = LookupListDA.VendorTypes;
}

The data layer shown in the example caches each lookup list internally the first time its property getter is accessed, so we can assign them to variables that are never used here and effectively "pre-fetch" our lookup list data while the user is waiting in the main menu, for example.

Using a lambda statement (anonymous method), we can consolidate this into a single named method, and avoid cluttering our class with a potential plethora of methods that may perform some ad hoc background thread processing.

protected override void OnStart()
{
    Thread t = new Thread(new ThreadStart(() =>
    {
        var c1 = LookupListDA.CustomerTypes;
        var c2 = LookupListDA.SalesOrderStates;
        var c3 = LookupListDA.VendorTypes;
    }));

    t.Name = "PrefetchLookupData";
    t.IsBackground = true;
    t.Priority = ThreadPriority.AboveNormal;
    t.Start();
}

After a little reflection, I came up with a similar pattern that further encapsulates the details, and in doing so, created an abstraction called LogicStream.  Other names that work are ExecutionStream or CodeStream, with the central concept being that you're specifying a sequential set (stream) of instructions that runs parallel to the stream that defines it.

protected override void OnStart()
{

    new LogicStream("PrefetchLookupData", s =>
        {
            var c1 = LookupListDA.CustomerTypes;
            var c2 = LookupListDA.SalesOrderStates;
            var c3 = LookupListDA.VendorTypes;
        });
}

Like the second example, this approach doesn't require a separate method, but it's also completely self-contained: there is no thread manipulation code outside of this code block; any setup we need to do can either be done via parameters ("PrefetchLookupData" names the thread) or by specifying an additional code block for thread configuration (an example is shown below).  Finally, the LogicStream constructor immediately invokes the thread, which is a background thread by default, so nothing additional needs to be done.

Here's a slightly more complicated example, showing how you can configure the thread and pass in multiple parameters.

using System;
using System.Threading;

namespace Demo
{
    class Program
    {
        static void Main(string[] args)
        {
            Thread.CurrentThread.Name = "Main";

            new LogicStream("ThreadX", s =>
            {
                // rename parameters passed into thread
                string ExtraInfo = s.Get<string>(0);
                int StartIndex = s.Get<int>(1);
                int EndIndex = s.Get<int>(2);

                // do work
                for (int x = StartIndex; x <= EndIndex; x++)
                {
                    Console.WriteLine("x = " + x.ToString().PadRight(10) + s.Name);
                    Thread.Sleep(50);

                    // this code has access to the Thread object via the LogicStream
                    if (x > 90)
                        s.Thread.Abort();
                }
            }, "Width Data", 0, 100); // optional parameters passed into the LogicStream

            new LogicStream(t =>
                {