Skip to main content

Making your domain less mutable

This happens regularly to me (and from my anecdotal investigation everyone involved in large / old projects). We need a new piece of functionality. I write it, it's beautiful and I win the internet. I have estimated 8 days (or 22.23 lol-points depending on how you live) and it's only taken 4 days.

Ah, but then a very small; mostly ignored and very unimportant detail rears it's cruel head. You need to make it work with the code that exists already. This is normally in the form of saving to some pre-existing entities. Oh dear. You save everything through the various management / service classes that exist already and nothing works. So begins the next couple of days of horror.

You find that you didn't set the work = true. Most of my woes in this area are caused by modifications at layer further down (or the stored procedure it finally ends up in) changing the object that I was trying to save or not saving part of the object because of some rule.

So many errors are caused by objects being used and abused and then changed or properties being altered somewhere by someone you weren't expecting. I have a couple of tips to help try and mitigate these problems. Of course, as Devs this shouldn't happen, you should test everything, other people should test everything, it should pass code review and so on and so forth. However that's all well and good but you aren't in control of the future. You don't know what the level of skill of the devs who pick up your code base in the future will have and you don't know what procedures will be added / removed.

Keep classes sealed!

Don't let your class be abused by some future fiend. Unless you are writing something specifically as a base class, the likelihood of it needing to be inherited from is slim. More likely is that someone is trying to do some good old fashioned lazy code-reuse by inheriting your lovely class instead of refactoring the functionality. Of course if a genuine reason crops up the future for the inheritence.... er, just change it! But let the need drive what you do.

Make constructors internal

Stop your object being created in the wrong assembly by making the constructor internal. This way, you can retrieve the object from the repository but you can't create a random new object for who knows what. You might not always need to do this, but I like to allow a command object or other method of instruction to create an object, this keeps the knowledge of how the object is created and what business rules need to be applied out of the calling assembly.

Control how your properties are set

Make properties private set or use public readonly fields that are set using the constructor. If you can at all, try to make changing an object once it exists, as difficult as possible unless your intention is for the property to change for a specific reason. The reason I love F# is that you have to specifically call a value mutable if you need it to change and it's discouraged.

Use an interface to control mutating an object

I stopped using this a couple of years ago as it seemed overkill but then recently we ran into problems of abuse again and although you can help people when you work somewhere and you can leave documentation and coding conventions you need to think about your legacy. Explicitly making the object be cast using the interface (object as IEditableObject) means you can control how the object is updated. If you make the interface internal to the correct assembly too you can stop people just getting an object out of the database, saving it and bypassing any logic that should have been applied.

From the above, if we now try to use some of the functionality from a calling assembly (for example the website or application assembly). We are very limited to how we can interact with the object. In this case, we are limited to pulling objects out of the repository as readonly objects and we have to use a command object if we want something to happen. Obviously the command object very well could be a "service" or whatever method you fancy using.

Comments

Popular posts from this blog

An instantiated object should be "ok"

I've been QA'ing quite a bit of work recently and one common theme I've noticed across both Java and C# projects I have been looking at is that we occasionally open ourselves up unessacarily to Exceptions by the way objects are being created. My general rule of thumb (which I have seen mentioned in a Pluralsight video recently but also always re-iterate in various Robust Software talks I have done) is that you shouldn't be able to create an object and then call a method or access a property that then throws an exception. At worst, it should return null (I'm not going to moan about that now). I've created an example below. We have two Dojos, one is good and one is bad. The bad dojo looks very familiar though. It's a little class written in the style that seems often encouraged. In fact, many classes start life as something like this. Then as years go on, you and other colleagues add more features to the class and it's instantiation becomes a second

Accessing the UI Thread with Tasks in F#

I have a Windows Forms program written in F# that can deploy a code base to n number of sites at once (you select the sites you would like to deploy to and it goes off and completes a number of tasks (backing up current sites, various unpacking and moving of files etc... ). Once you start it, it begins it's merry journey and begins to update the UI with what has happened. At the moment this method of updating the UI is not pretty because the threads I am doing the work on can't update the UI so I perform some fiendery to make that happen (don't ask). I knew there was a better way using some newer .NET features but I just hadn't got round to having a fiddle yet. I have now found that if you use the built in Task class but break your code up in a nicer way and then chain the tasks together you can then pass the correct context into the task that you want to talk to the UI. Here's a little script to give you a feel for it. You can press the "start" butt

NESTA - Next Gen.

via nesta.org.uk Following on from an article on the BBC about Raspberry Pi, this next gen report has some interesting findings. The scariest stat which I picked out from the BBC website was "out of the 28,767 teachers who were awarded Qualified Teacher Status... in 2010, only three qualified in computing or computing science as their primary qualification" Having worked as a computer science teacher for a year in a school that was a specialist in Computing I can concur that the uptake in Comp Sci was woeful. 2 Students for A2... The other teachers backgrounds in Computer Science was also fairly woeful (most knowing a bit about Office but still a paltry amount even about that). I couldn't speak for my counterpart that I was covering however. I suspect they were fairly up on things. All in all what kills me is that Computer science is not a secondary level subject. Areas are often covered, a little in IT, a little in DT subjects (if kids choose Systems and Contr