Nerd Fortress

Ever wonder why the C++ STL uses an external, non-member function model for implementing algorithms for containers? The following article sums it up. Although a few of the “no less efficient” examples are debatable, the underlying principles definitely have merit.

Monoliths “Unstrung”

One downside to the functional approach outlined in the article–that I didn’t see mentioned–is the fact that the interface is actually being split in a few cases, which is actually detrimental to cohesion. This happens when you have multiple overloaded forms of a function, and you keep one “flexible” one as a member function, but make the others external functions. Why not keep those as members for the sake of consistency? You can still implement them in terms of the one “flexible” member function, thereby continuing to ensure good encapsulation.

A few thoughts on applying the spirit of the law discussed in the article to other languages:

• C# – Use extension methods, but the “this” type should be as generic as possible. You still get the benefits of DRY but in a more object-oriented fashion that works well with Intellisense and cohesion. I like the extension  method approach better than the old static-methods approach (e.g., string.Join) because it still enforces good encapsulation, and is less verbose and more cohesive than the alternative.
• Ruby – Use mix-ins that use duct-type delegation to other methods. These can be automatically mixed into all applicable classes when the mix-in is “required”.
• Lisp – Brilliant! All you have are functions!

It’s also important to note the power you derive from combining this functional approach with lambda functions, function objects, and covariance.

See also: How Non-Member Functions Improve Encapsulation

While testing some web services, I was not-so-pleasantly surprised to find that WCF cannot disambiguate two methods when one is a GET nd the other a POST:

[OperationContract]
[WebDispatchFormatter]
[WebGet(UriTemplate = "/{encodedGameId}?startDate={startDate}&endDate={endDate}&tag={tag}")]
Contracts.Out.Statistics GetStatistics(string gameId, string startDate, string endDate, string tag);

[OperationContract]
[WebInvoke(UriTemplate = "/{encodedGameId}", Method = Verbs.Post)]
void AddSample(string gameId, Contracts.Sample newSample);
[WebDispatchFormatter]

If you leave off any of the query parameters for GetStatistics, WCF cheerfully returns “Method not allowed”. I wanted to make the “tag” parameter optional, and worried this would be a deal breaker.

Fortunately, I came across this WCF post by Ron Jacobs.

The basic idea is to leave off the optional query parameters in the UriTemplate, instead manually pulling them from the current request context. This approach is actually similar to the way you access query parameters in RoR, so I should have thought of doing it like this in the first place.

In fact, if you beef up Ron’s QueryString class, it can clean help you DRY up your code by taking care of data type conversions on the sly.

The moral of the story is that a framework’s design can induce sneaky biases that you only discover as they jump out of the shadows to bite you.

Thanks Ron!