// TODO: Add Comments

In the game 20 questions one player thinks of something and the other players ask yes or no questions in an attempt to determine what the first player is thinking of.  The first player considers each question in light of his privately held information and replies with the appropriate response. This is a great model for encapsulation.  The first player thinks of an object and holds it in memory, and the details of the object are not available to the other players (private state).  Other player ask questions (invoke behaviors) to gather information about the object.  The behaviors are limited to yes or no questions and consist mostly of a common, predictable set of useful questions:  Is it an animal, vegetable, or mineral?  Is it bigger or smaller than a breadbox? Is it something you eat? etc. Suppose the game ends without a successful guess, and the first player thinks of another object for the next round of questions.  The new object replaces the ...

Determining what state or behaviors to expose on an object can be difficult.  We all know the basic rules—encapsulate logic, only expose immutable value objects, and so on—but putting those rules into practice does not come naturally.  In fact, given our heritage of anemic, relational models, it’s almost unnatural .  Several years ago I remember reading about SOLID and other OOP principles and thinking to myself, how on earth would you persist that? Of course not all objects are persistent, and having the benefit of experience I now know that the view, domain, and persistence models need not be one and the same.  That being the case, there are incredible benefits to encapsulation, if done properly.  But how exactly does one put aside relational habits? One trick I have is to imagine objects have personalities and imagine how they would react if I asked certain questions or requested certain behaviors.  For example, suppose I had a Person object and I w...

When I first read about the visitor pattern I did not understand why it worked or how it would be useful.  Now, many years later, I finally understand why it works, but until recently I haven't encountered a situation where the visitor pattern was superior to alternative patterns. Today I came across a problem in which the visitor pattern actually seemed to offer some value in real code.  A data contract specifies a message containing a member with an abstract data type.  The caller is expected to provide a concrete implementation of that abstract type (one of several known DTO types) in the message.  When the message is received, the concrete object must be mapped onto a corresponding domain object.  Then after the request has completed, the domain object must be mapped back onto the DTO type for inclusion in the response message.  Both the DTO type and the domain object type are polymorphic, so the concrete implementations are not at all impo...

A while ago I came across an excellent presentation by Dan Bergh Johnsson on the topic of value objects. There is nothing revolutionary in this talk, but it was a good reminder of what value objects actually are and where they should be used.  While the ideas in the video stand on their own, it is interesting to see how they complement and simplify pre- and post-condition checks on methods with code contracts. Consider the following example (using Microsoft code contracts) in which a domain name is added to a collection that does not allow duplicates: public class DomainNameList { private IList<string> _domainNames = new List<string>(); public void AddDomainName(string domainName) { Contract.Requires(!string.IsNullOrWhitespace(domainName)); Contract.Requires(!Contains(domainName)); Contract.Requires(ValidationUtil.IsValid(domainName)); _domainNames.Add(domainName.Trim()); // Trim to ensure whitespace does not affect Equals ...

The other day I stumbled across " Is it Possible to do Object-Oriented Programming in Java ", a video presentation by Kevlin Henney hosted at  InfoQ .  I had expected the same tired comparisons to Smalltalk and C++, but I was pleasantly surprised.  Despite the talk's title, it had very little to do with Java;  the bulk of the discussion centered around abstraction.  The one thing that really stuck with me was the purist notion of writing code such that concrete classes appear only to the right of "new" operators, and using interfaces everywhere else (even in concrete implementations of equals and hash code functions). So in a new project I've been experimenting with this.  I started by identifying all of the types and services I would need to deal with and defined them as interfaces.  The arguments of each method call are defined in terms of either primitives or interfaces.  Whenever I had to deal with concrete types in the underlying ...