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”

C# equality in depth. Part 1: Basic == equality

Equality in C# is an odd beast. At first glance, it seems very simple. Value types are compared by by value, objects are compared by reference and the comparison method can be overridden by a class if it wants to. For example, the String class compares the string contents, rather than comparing by reference. There are also sensible “best practice” rules suggested by Microsoft, such as avoiding comparing mutable objects by value, only by reference. All is not as it seems though as the following series of NUnit tests show. All the tests pass and thus demonstrate some aspect of equality in C#. Continue reading “C# equality in depth. Part 1: Basic == equality”

Posted in C#

C# equality in depth. Part 2: .Equals() and == are not equal

The two ways of checking for equality in C# – using == and .Equals() – can be modified for individual types. It is important to remember though that override and overload are two very different things in C#: .Equals() can be both overridden and overloaded, whereas == can only be overloaded. This set of tests demonstrate the significant effects this subtle difference can have on equality comparisons. Continue reading “C# equality in depth. Part 2: .Equals() and == are not equal”

C# equality in depth. Part 3: IEquatable

With .NET 2.0, Microsoft introduced the IEquatable interface. It introduced a typesafe Equals() method that could be used to speed up comparisons in the new generic collections. It speeded up those comparisons by avoiding the need for casting and boxing, which the Object.Equals() suffered from. The IEquatable interface is a dangerous beast though as it can lure the unwary into thinking it rationalised equality in C#. This set of tests sets out to demonstrate how quite the opposite occurred: it simply made things worse. Continue reading “C# equality in depth. Part 3: IEquatable”

Posted in C#

SuccincT – A .NET framework to solve unexceptional exceptions & out parameter annoyances

SuccincT iconThe .NET framework is getting on a bit. Many users of the .NET framework are either resistant to API changes, or are stuck with binary-only 3rd party tools that would break with API changes. As a consequence of these two things, the .NET framework has aspects to it that go against modern thinking, but we are stuck with them. The solution to this is often to encapsulate those features within newer frameworks, which offer “best practice” facades on to those features. SuccincT is one such framework. Continue reading “SuccincT — A .NET framework to solve unexceptional exceptions & out parameter annoyances”

QCon London 2013 – Day 2

QCon logoQCon is a large conference, with around six parallel tracks, offering talks on a range of subjects. Normally when visiting QCon, I skip between these tracks as the day progresses. That was certainly my plan for day 2 this year, but as the day progressed, I realised one track offered me a great opportunity to take away a good cross-section of ideas; ideas that some might no doubt find controversial: agile can be too process-bound and people are more important than processes. Continue reading “QCon London 2013 — Day 2”