ThoughtShapes Shaping Ideas With Thought

The work a system does and the interface to that work should be separated from one another. This is a concept that evolves from the Single Responsibility Principle and from Test Driven Development. Whether this work be hosted in a console program, a GUI program, exposed as a service for outside systems to utilize, or any other possible configuration, follow SRP and keep the work separate from the hosting interface that exposes the work to a client (a client in this case can be a person or another software system).

Rjae, Rob, Kasia Baron, and I went to the Deep Agile 2008 conference run by New England Agile Bazaar. The event was held over the course of two days at MIT's Tang Hall and was truly outstanding. The structure of it, as noted at Agile Bazaar's website, was a one-on-one discussion, debate-style, between Robert Martin and James Coplien and it focused on the realities of Agile software development.

One of the most ubiquitous patterns in life is the template. It enables us to generalize behavior - thus ignoring or postponing complexity.

This ability to generalize behavior - deferring derivative details - turns out to be extremely useful in agile software development. It encourages mock-object practices. It encourages simplest possible solutions. It encourages test-driven development. And most importantly it embraces change.

We present the following principles:

• SRP: Single Responsibility Principle
• OCP: Open-Closed Principle
• LSP: Liskov Substituation Principle
• DIP: Dependency Inversion Principle
• ISP: Interface Segregation Principle

What do you call a Singleton that does not prevent more than one instance from being created? I call it confused. That is precisely what I was upon discovering the default effect of WellKnownObjectMode.Singleton in .NET Remoting. As I worked around this default behavior I realized my discovery and solution would be useful to others. This post discusses the differences between Singleton and Monostate, proves why a Remoting Singleton is Monostate by default, and shows how to design a true Singleton for .NET Remoting. It also includes several unit-testing tricks along the way!

In the next session(s) we will be focusing on how to make one’s tests database independent. This includes two primary goals:

Testing UI code is often considered too difficult or even impossible. In this session we introduce dependency injection and factory pattern to make testable assertions of our UI code.

This session continues development of a proposed master person index.

Adherents to Domain Driven Design (DDD) often struggle with how to structure the “layers” of their application with respect to where object repositories should be placed. As usual in software development the answer to this quandary is “It depends”. In this posting I’ll discuss several things that should be taken into consideration when making this decision.

Repeat after me: Interfaces and OO are my friends.