Using Succinc<T> to overcome IEnumerable code smells

SuccincT
The IEnumerable<T> interface has numerous extension methods associated with it, including a number that return a single element if a match occurs, or return the default value for the type if that fails: FirstOrDefault, LastOrDefault, SingleOrDefault and ElementAtOrDefault. These methods create two code smells due to the nature of .NET’s type system. As of version 1.5.0, Succinc<T> offers alternatives to these methods that overcome those smells.
Continue reading “Using Succinc<T> to overcome IEnumerable code smells”

An example of a benign Service Locator

In my last post, I examined whether or not the Service Locator is an anti-pattern. The conclusion was that it isn’t. Instead it’s a code smell that all too often causes another anti-pattern to occur: hindering easy testing.

One of the reasons cited for why it’s only a code smell is due to edge cases where a service locator can be used internally within an assembly as an implementation detail that doesn’t affect testing. It’s natural to ask what such a test-friendly service locator might look like. The Visual Studio/MSBuild and .NET framework combination supplies such a locator: .resx files and the ResourceManager class.
Continue reading “An example of a benign Service Locator”

Is the Service Locator an anti-pattern?

Recently, I’ve been reading a number of articles arguing whether the Service Locator pattern is in fact an anti-pattern. On one side of the fence, there are those that argue yes, such as Service Locator is an Anti-Pattern by Mark Seemann and Service Locator is Indeed an Anti-pattern by Nick Hodges. There are those that argue the opposite though, such as Service locator is not an anti pattern, by Jonas Gauffin. Continue reading “Is the Service Locator an anti-pattern?”

Poor man’s DI is dead; long live Pure DI

One of the last posts I wrote before disappearing off the face of this blog for nearly two years was “Are IoC Containers a case of ‘The Emperor’s New Clothes’?” there were two main points that I was exploring in this article that bugged me at the time:

  1. All too often, people seem to come up with dreadful implementations of IoC that either exposed all of their application to the container or they used some sort of “God object” container to handle injection into every part of the application.
  2. The way to avoid the above problem was given the rather insulting term “Poor Man’s DI”, which was unhelpful as it naturally discouraged those learning about DI from using it.

Continue reading “Poor man’s DI is dead; long live Pure DI”

Are IoC containers a case of “the Emperor’s new clothes”?

Someone, using a gun labeled 'IoC container', aiming at their footI don’t use IoC containers. Many of the best developers I know swear by them. More, three incredible people who have taught me so much over the last few years – Shaun Smith, Stray and Till Schneidereit – even developed their own, very popular, IoC container: RobotLegs. Yet I don’t use IoC containers. I’m a big fan of dependency injection and a passionate advocate for the return of the death penalty for the singleton and service locator patterns. Yet I still don’t use IoC containers. Is the reason I don’t use them because IoC containers are a case of “the Emperor’s new clothes”? Continue reading “Are IoC containers a case of “the Emperor’s new clothes”?”

Are design patterns compatible with modern software techniques?

Design patterns: who really uses them? Are they just ways of overcoming limitations in Java? Are they an idea that has had its time? Do they really aid understanding of ideas between programmers, or do they just cause more confusion? Or, are they a great, but often misunderstood, idea that is still relevant today and that can be applied to all languages? After much thought and discussion with unsuspecting folk who have suffered a string of daft questions from me, I finally feel able write down my take on software design patterns and my conclusions might surprise many that know me. Continue reading “Are design patterns compatible with modern software techniques?”

Why we absolutely should never build software like we build houses

Image of a madly designed houseA few days ago, I read something truly depressing. It was a piece written by Leslie Lamport, “a computer scientist … member of the National Academy of Engineering and the National Academy of Sciences. [with a] Ph.D. and M.A. in mathematics from Brandeis University and B.S. from MIT [and he] works at Microsoft Research.” Yet for all these grandiose accolades, he demonstrates a depressingly clueless understanding of his subject matter: software. In his article, he argues that we should build software like houses. In this article, I’ll detail why attempting to create applications in the same way as building houses is a really bad idea, which held back software development for decades. Further, the reality is that these days, architects are more likely to design houses using techniques pioneered by the latest software development practices. Continue reading “Why we absolutely should never build software like we build houses”

Lapsang: does the world need yet another programming language?

Lapsang logoIn every programmer, there is (or at least there ought to be) a budding language designer just waiting to get out. However, before you or I rush off and knock up yet another programming language, let’s take a quick trip to the world of the novel. Remember the phrase “everyone has a novel inside them”? It’s a often repeated phrase, yet to slightly misquote Russell Lynes, the true phrase probably ought to be “everyone has a novel inside them, and [in most cases] that’s the best place for it.” So maybe it’s a good thing that most programmers never express their inner language designer. Despite this, being a master of turning my back on good advice, I present to the world, Lapsang… Continue reading “Lapsang: does the world need yet another programming language?”

I was wrong regarding the private keyword. Here’s why

Sometime ago, I wrote what turned out to be a highly controversial post in which I argued that private members should be avoided as they caused more problems than they solved. Two years on, I have come to realise that I was wrong and that problems with private members are simply symptoms of bad written code, rather than problems in their own right. Continue reading “I was wrong regarding the private keyword. Here’s why”