Adrian Alonso

Pair programming is a well known eXtreme Programming practice. Nowadays it is very frequent that developers aren't in the same physical place so it would be interesting that the IDEs could offer us remote functionality to develop with a person that could be in another part of the world. If you think that it would be useful, let’s try to define some of the potential add-ins to the IDE:

• To have a way to edit remote code and that the changes would be saved in the remote machine. This may be something like VNC client.
• To have a way to communicate with other developers without exiting the IDE. Something like a chat embedded in the IDE including text, audio and video.
• ...

Beyond the practice, this could help to assist junior developers in the typical problems that they usually have, yet we were in the same office (this let us not to get up of our chairs).

Labels: Methodologies

OB is a very powerful tool but it's not well documented yet, so I was thinking the didactic way to show how it can be used and extended by any project (such as tools, business projects, core utilities, etc).

The starting point is to use the existing material:

• CAB’s doc
• kzu's webcast on p&p
  
• EntLib and OB by Brian Button
  

Then, I think it would be useful to meet with an “OB.chm” (or equivalent) that offers an introduction, explains the design principles to understand how to extend it, shows some scenarios where it can be used and includes the existing material and examples of the typical use cases.

Another good thing would be to have a community site where developers can upload custom strategies or policies, post comments and … well, you know. As far as I know the site’s publication is imminent.

Concerning development, a DSL (see DSL tools here or here) with a Guidance Package (see GAT) could allow an alternative to programmatic configuration and would be an excellent tool to reduce the OB’s learning curve.

As a preliminary prototype, I started a doc with the following topics:

• Introduction
• Terminology (LEL style - Language Extended Lexicon)
• Design of OB
• Policies
• Design Patterns used by OB
• Strategy (GoF)
• Chain of Responsibility (GoF)
• IoC or Dependency Injection
• Extending OB
• With strategies
• With policies
• Comparison with to Spring’s BeanFactory
• Reference to how CAB and EntLib uses OB
• Examples
• …

As soon as I have a “cleaner” version, I will try to upload the doc to some site or keep on posting.

Labels: .Net

Let's talk about a cool tool named ObjectBuilder that is a subsystem used by CAB and EntLib to perform the repetitive job at the moment of creating objects.

ObjectBuilder (OB) is a Pattern & Practices Application Block. The owners of the project define it as “a framework for composing object-oriented systems”. OB was conceived in CAB (Composite UI Application Block). It uses the Dependency Injection pattern to populate object’s members via Constructors and Property Setters strategies. (To read more about Dependency Injection, see Martin Fowler’s article about what dependency injection is and how it is implemented by various frameworks).

OB can:

• Create the appropriate objects based on configuration data.
• Manage Singleton pattern.
• Populate public properties and execute methods on the object.
• Communicate with objects that support the IBuilderAware interface.
• Provide a tear down facility that can remove settings from objects by reversing the chain of operations.

The main concepts of OB are Strategies, Policies, Locator, Lifetime Container and of course the Builder. The OB's design is based on the "GoF Builder" design pattern. This pattern is categorized as a stateful creational pattern because we first setup the builder and then tell him (yes, tell don't ask) for a new instance... so, generally an example says than a million word...

1. Builder builder = new Builder();
2. Locator locator = CreateLocator();
3. builder.Policies.Set<ISingletonPolicy>(new SingletonPolicy(true), typeof(Foo), "foo");
4. Foo obj1 = builder.BuildUp<Foo>(locator, "foo", null);
5. Foo obj2 = builder.BuildUp<Foo>(locator, "foo", null);
6. Assert.AreSame(obj1, obj2);

First, in 1 and 2 we create a Builder and a Locator. Then, a Singleton Policy is added to the builder (line 3). The line 4 tells the builder for an instance of Foo and line 5 tells for another instance. Finally, the line 6 asserts that the obj1 and obj2 references are the same so the Singleton Policy works ok.

When BuildUp method is fired, OB lunches a chain of responsibility (yes, another GoF design pattern), using all Strategies that internallyhas, in order that for each strategy uses to decide whether it must execute using the configured policy.

OB has a lot of more power but it is not well documented yet. By now, you can find some bits in CAB's documentation and in meaningful blogs as kzu and brian button

Labels: .Net