Obvious Code – //TODO: Fix

Capturing Requirements – A How To Guide. Part 1: What do you mean I have to talk to people (in which I largely avoid talking about the topic)?

It’s a common cliche that us techies can be socially challenged.

This is a cliche

I’ve long disliked the comic above, it’s patronising, it’s out of date, it’s offensive, and most of all it panders to a stereotype that I now feel an onus to challenge by becoming a better communicator, which means talking to people – icky, messy, complicated and illogical people like users, people who have needs and requirements and don’t appreciate the wonder and beauty of my code.

The costing rules need updating? That’s awesome, because I have a brilliant IOC pattern at the base classes of the rates engine, employing a Strategy Pattern with some really cool Reflection that means I only have to write five lines of … will you please stop looking at your phone whilst I’m trying to tell you what a great developer I am

Continue reading →

Single Responsibility is Hard Part 2

This is part 2 of my series in which I largely whinge that complex problems wrapped in simple terminology are, in fact, complex. Part one can be found here.

I delayed writing this post for a week or so, as I was struggling with the idea that I was discussing something in isolation, SRP, that really needs to be looked at in collaboration with the rest of its brethen, namely the OLID. Eventually, however, I decided not to delete the last post and carry on with another topic, largely as SRP is often flirted with in isolation.

Why this is, I think, as I mentioned in my last post, is it appears the most accessible and obvious. Skimming through a page on SOLID you see a paragraph discussing the statement `A class should have only one reason to change`, and a paragraph discussing what the meaning of `Liskov Substitution Principle` is.

The path of least resistance is, frankly, the paragraph made up of words you understand.
Continue reading →

Single Responsibility is Hard Part 1: A long and explanatory ramble

As with many developers, I’ve flirted a lot with Uncle Bob Martin‘s SOLID principles, and honestly believe they have helped me build far more scalable and serviceable code than I would have written otherwise.

Now, there are many articles, examples and projects on SOLID already on the web, so I don’t want waste too much time repeating everything here, simply for the sake of a blog post (though it’s possible I will discuss them all sometime or another). Instead, in these posts, I want to talk about the just the S in SOLID, Single Responsibility Principle, and what a right mess I can make of it.
Continue reading →

Json Messaging with C# Part 3: Message Handling

In part one of this series on JSON Messaging in C#, I looked at building self serialising and deserialising messages.
In part two, I discussed some of the options in identifying received message types.

In this, final, post, I want to look at handling differing types of messages in a simple and scalable fashion.
Continue reading →

Json Messaging with C# Part 2: Message Types

This post is the second part of three posts about Json Messaging.

Part 1 is here
Part 3 coming soon.

In this post I want to discuss a small problem about self deserializing messages.

If we consider that we can rebuild our object from messages, simply by using:

1
MessageOne message = MessageOne.From(json);

the question arises, how do we know what type of message our received json text is? What Class do we use to call our static From method.

Continue reading →