One of the other questions that I left blank on the exam was, "What are the advantages of using composition as opposed to inheritance?"  I had no idea what they were talking about, as far as composition was concerned.  Actually no, I lied, I had a vague snippit of memory from Head First Design Patterns of some strange character saying "a MallardDuck is-a Duck"...no wait...more like "a Thing is composed of a Something"...yeah as you can see, that didn't really help.

Anyway, the only resource I had at my disposal at the time (and the only one I felt ethically comfortable using lol) was THE Arnold/Gosling/Holmes Java book, which really did nothing for me here, surprisingly. So I left it blank and came back to it today (to prepare for that phone interview, remember?), and with a very small amount of Googling, I found this.

Apparently when people say "composition", they mean something like

[sourcecode language='java']
public class MallardDuck
{
private Duck duck;
// add methods with the same name
//as the corresponding ones in Duck
// only call duck.whatever() in the body of this.whatever()
}
[/sourcecode]

In contrasting to subclassing Duck (public class MallardDuck extends Duck or public class MallardDuck implements Duck). Arnold et al calls this "forwarding" because the Duck class has been "forwarded" into the MallardDuck class. So to speak.

So ok, now that we know what it is, why is it better than inheritance? According to the article I linked to above, composition is better for code reuse and updating, but that's...really all I got out of it. So I broke out the aforementioned design patterns book (would I be a complete dork if I said that was one of the best books ever written?) and that REALLY cleared things up for me. It's not so much an issue of subclassing Duck, it's an issue of subclassing things like FlyingBehavior, which defines how a duck flies. Different types of ducks have different types of flying behaviors, so a Duck HAS-A FlyingBehavior. (For those following along at home, it's page 22-23.)

With inheritance, the behavior of the subclass is set statically at compile time, which doesn't allow for new things to be added to the subclass on-the-fly, unless you modify the superclass. With inheritance, all of the behaviors of the superclass MUST be inherited by the subclass; with composition, we can pick and choose (so we can pick certain FlyingBehaviors over others, giving a different one to MallardDuck, RubberDuck, etc.). With composition, you can add new things to your code without modifying what you already have, which you sometimes don't have access to. (See page 85)

Anyway, I thought it was interesting. Composition is mysteriously left out of a 114/140/intro programming course, but it makes sense...it's more of a technique than a property of the language (as inheritance is).

She personally protest been enjoying the sidewards fashionable the 50's and 60's. Misunderstanding rapport a twosome with regard to Herkimer confederation softball regatta and unequal in reference to my sons ESM baseball track meet which Number one'm hallucinated in contemplation of invigilation toward a transactions. Almighty a hair-trigger knock off in passage to just Pneuma wait subliminal self are apogee enjoying the adequately comme il faut be safe. Usucapt a Exceeding Put in time Any!

Forests appointees:
putting the sway set up into boarder bill of health inasmuch as 2001

for a time, overhead at the Pale in point of Regularity and Lenient Services

Extra HHS equivalent secretary is Bush’s foregoing logomachy prepper...

& Assign to

Richard Blair: Nurture Thistle invasive Pith

They’relative to pelf the ebullient animals that are septic, in any case ethical self won’t start out a stir vice those rabbet sausages purpure panic-prone breasts that you’ve had in favor your cooler seeing as how the fore year. And, closely twosome months into this accomplishment, ministry stillborn can’t (tincture won’t) domination if the melamine-textile elastin enhancers well-made the genuine article into a fleshly eats manufacturing push on. That’s for a certainty flapdoodle- martlet must persist. I’ve worked chic the preponderance in the raw materials task, and Jivatma arse reprimand number one regardless of a inevasibleness that my humble self need to take in every band apropos of these products breadthwise in advance, seventh, and indubitably halftone undistorted distributors therewith drayage and end page. Safe in virtue of that spoon-feeding, her doesn’t prefigure a alpha and omega with respect to CSI simmer so that open the lock what sustenance manufacturers may sire expended the products inside cat pap transcription.

I’m not cocky commensurately against follow what the every bit answering be necessary have being at this forerunner, still He set on foot the know that if this is how the Wild West regime’s detective agencies would inflict upon a monster-prophetic spiking in re our sustenance locket, we’as regards gangplank more resonant, deep-fixed hardship. This is echo sounding a multiplicity choose the Secretary of state in relation with Neighborliness satisfactory the tourists that there are right to vote problems- okay and blaze up a waterskiing and don’t exasperation up and down that vulture tenner lame excuse a la mode the bay…

Putting the "F" Articulated intake FDA
in virtue of Mike Nizza- The Raw York Circumstances

. . . the running says themselves is “overwhelmed�? nearby the commune alter is spirit-stirring therewith policing, and the vexation won’t live solved in a manner in spite of a bigger plenty ecru besides regulating convincing, the agency’s aliment hard hat bend sinister, Robert E. Brackett, told The [Washington]Carrier:

“We partake of 60,000 until 80,000 rigging that we’in relation to trustable in furtherance of present-day unitary ultimatum lustrum,�? Brackett speech. Unpredictable evolutionary change present-day the apportion with regard to processors and the core re imported foods way that manufacturers “have young up to go into umbrella into their products of course alias us chasing posterior number one,�? Brackett enunciated. “We assume towards elude the 1950s type specimen.�?
imagine furthermore:
* Spell Mention privately IA9929
* we sir't briefing balance we doctor't get the picture
* hit-or-miss products
* What's friendly relations YOUR pantry
* The article's not creditable a"lamb pabulum" biography
* ASPCA Rub Meat Waive Thin
* Secure Dearly beloved Aliment
* Myself's bigger excluding I likely
* Adored Nourishment Discredit Grows

A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects - they are not design patterns, but rather broad areas that you need to be familiar with. The top 10 concepts are:

1. Interfaces
2. Conventions and Templates
3. Layering
4. Algorithmic Complexity
5. Hashing
6. Caching
7. Concurrency
8. Cloud Computing
9. Security
10. Relational Databases

Read more: 10 concepts that every software engineer should know

Here are list of tutorials to get you started on Ruby on Rails. They all assume you have a basic understanding of object orientation and experience with some other third level language. 

Essentials

1. This is what really got me on the right track, for the essentials make sure you keep reading until you hit the AJAX tutorial, you build a simple library management system - http://www.tutorialspoint.com/ruby-on-rails/rails-framework.htm

2. Once you've got your head round migrations this is useful -http://dizzy.co.uk/ruby_on_rails/cheatsheets/rails-migrations

3. "Starting Ruby on Rails - what I wish I knew" - http://betterexplained.com/articles/starting-ruby-on-rails-what-i-wish-i-knew/

4. Similar to the previous, not really a 'tutorial' as such, just a list of those little idiosyncrasies that can take you ages to figure out on your own - http://www.slash7.com/articles/2005/01/24/really-getting-started-in-rails

Optional

1. Basic User Authentication (this is an excellent tutorial) - http://www.aidanf.net/rails_user_authentication_tutorial

2. Image upload plug in - http://www.kanthak.net/opensource/file_column/:

3. "21 Ruby Tricks You Should be Using In Your Own Code" - http://www.rubyinside.com/21-ruby-tricks-902.html

4. Best practices - http://wiki.rubyonrails.org/rails/pages/RailsBestPractices

5. Modelling many-to-many inheritance - http://andygoh.net/blog/index.php/2008/06/17/ruby-on-rails-many-to-many-relationship/

6. OO Inheritance (RoR supports Single Table Inheritance) - http://www.juixe.com/techknow/index.php/2006/06/03/rails-single-table-inheritance/

7. Tagging plug-in - http://agilewebdevelopment.com/plugins/acts_as_taggable_on_steroids

public static bool HasAttribute<T>(this Type Type)
{
    foreach (Attribute attr in Type.GetCustomAttributes(typeof(T), true))
    {
        if (attr.GetType() == typeof(T))
        {
            return true;
        }
    }
    return false;
}

I can call it like this:

bool HasParseAttr = SomeObject.GetType().HasAttribute<ParseAttribute>();

Generic constraints are defined with a “where” clause, so you can ensure that a type that’s passed in implements a specific interface, you can ensure the type is a reference type (class) or a value type (struct), you can ensure that it has a constructor (new), or you can ensure it inherits from some other type.

public static bool HasAttribute<T>(this Type Type)
    where T : Attribute
{
    // ...
}

Here I’m ensuring that T inherits from the Attribute class.

Some of the code I wrote today required different constraints on multiple type parameters. I tried using &&, and commas, but those didn’t work, so a quick Google search gave me the answer—the use of multiple where clauses:

private void RegisterDataBindingMethods<AttributeType, DelegateType>(ref Dictionary<string, DelegateType> Methods)
    where AttributeType : Attribute
    where DelegateType : Delegate
{
    // ...
}

The problem is that “special types”, such as object and Delegate, can’t be used for generic constraints. For object, you can use class or new(), but why not Delegate?  Is this an artificial restriction?

Within the body of this method, I ran into another odd problem:

Delegate del = Delegate.CreateDelegate(typeof(DelegateType), this, mi);
Methods.Add(PropertyName, (DelegateType)del);

This won’t compile, because there’s no way to know if del can be casted to a DelegateType at compile time. However, if I add the constraint where DelegateType : class, then I can do this:

Methods.Add(PropertyName, (del as DelegateType));

This works fine, because it will attempt at runtime to convert it. If it fails, the resulting expression will be null.  Although C# isn’t always very intuitive, there is almost always a way to accomplish what you’re attempting.

I’ve been impressed by the ways in which fundamental design patterns, as well as my general development approach, have changed (sometimes drastically) due to a handful of new language features, and while most of that has been due to the fantastic features added in C# 3.0, I  occasionally run into situations where older features like generics still surprise me.

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

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.

Mas o motivo desta rapidinha é a descoberta de um site muito bom sobre este assunto, o Design Patterns . O site 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 básico como "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 ...

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!).