Using Succinc<T> to overcome IEnumerable code smells

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?”

Do you SHOF? Higher order functions in OO languages

If you live in the world of OO languages, you likely fall into one of two categories:

  1. You are still happily using inheritance, switch statements, nested if/else collections, have methods that are hundreds of lines long etc. You possibly haven’t heard of TDD or DI. There’s a very good chance that, if this is the case, you’ll likely never see this post as you likely do not read blogs by other developers.
  2. You do read around, you are aware of why inheritance, switch, deeply nested and long code blocks are frowned upon by the well-informed. You are at least aware of TDD, even if you haven’t quite started using it yet. Also, you are likely aware of the growing excitement around functional languages and perhaps look on with envy at some of their features. If this is you, you possibly already use SHOF’s without knowing it.

Continue reading “Do you SHOF? Higher order functions in OO languages”

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”

Introducing Succinc<T> – functional additions to C#

SuccincT logoTo certain extent, the title of this post is a little dishonest: it’s not really the first time I’ve introduced Succinc<T> on this blog. I first mentioned it over two years ago. To explain the title therefore, some history is required.

During early 2013, I was indulging myself in a “thought experiment” language: Lapsang. One such thought experiment was around the idea of whether a language could sensibly support the concept of not throwing exceptions for petty, unexceptional, reasons. Continue reading “Introducing Succinc<T> — functional additions to C#”

I’m back!

Two years ago (almost), I stopped posting to my blog. Two years ago (almost) I took the opportunity to switch roles within the company I worked in at the time from developer to development manager. The two events are of course linked. It was a big move for me. I’d previously been a team leader; I’d previously had responsibilities for managing groups of people, but each time I’d carried on spend at least some of my time developing code. This role was different though. This role was 100% management. Coding became a thing of the past. There was lots of new skills to learn: people management; product management; project management; finance; and – with hindsight the most important skill learned – expectation management of commercial desires of the company.

So why didn’t I blog about these new discoveries? To put it simply, I was unsure about what was appropriate to post; how to talk of what I was learning without compromising the commercial confidence of the company. I couldn’t post about the negatives and the positives always seemed almost mundane and hardly interesting reading for others. So time passed and the blog died a slow death… Continue reading “I’m back!”

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?”

Some thoughts on expanding SuccincT to provide richer interface contracts and auto-generated data classes

SuccincT iconRecently I created a very simple framework, SuccincT. At it’s core is the ISuccess<T> interface. As I explained in a previous post though, by itself that interface isn’t much use. C# lacks the ability to define constraints on an implementation of ISuccess<T>, save through comments. The idea behind it was that an implementation should throw an exception if its Value is read when Success is false, but there is no way to guarantee that an implementation will exhibit this behaviour. This bugs me.

Unrelated to SuccincT, I’m a fan of defining data objects via interfaces, rather than concrete types. By “data object”, I mean any object that encapsulates a set of values. These might be used to avoid multiple parameters to a method or constructor, or to return a complex data set from a method. Data objects need not be immutable or serializable; they just need to be simple to use without causing problems when it comes to testing. As I like to encapsulate data, I like the setters of data objects to be internal, which does cause problems with testing. Thus why I like to use interfaces: the test class can define its own implementation, rather than having to fight against encapsulation. However, for every interface I create, I have to create at least one class too. This adds needless code to projects, which also bugs me.

These two things – wanting interfaces to define a more detailed contract and wanting to avoid having to write data object classes that can be 100% inferred from the interface – set me thinking: could I create some way of extending interfaces and avoiding writing data object classes? Continue reading “Some thoughts on expanding SuccincT to provide richer interface contracts and auto-generated data classes”