Patterns

Template Method Pattern in Ruby

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.

Principles of Software Development

10/25/2007 - 6:00pm
10/25/2007 - 8:00pm
Etc/GMT-5
Boston .NET Architecture Study Group

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

Remoting Singleton Is Monostate By Default

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!

Database Independent Development

05/16/2007 - 6:00pm
05/16/2007 - 8:00pm
Etc/GMT-5
Boston .NET Architecture Study Group

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

Testing the User Interface

03/21/2007 - 6:00pm
03/21/2007 - 8:00pm
Etc/GMT-5
Boston .NET Architecture Study Group

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.

Where Should My Repository Live?

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.

Using OO to Avoid Branch Logic

Repeat after me: Interfaces and OO are my friends.

Syndicate content