Mark Needham

In our latest coding dojo we attempted to code Isola in Javascript but instead of coding from the board inwards we decided to try and take the approach of coding from the cells outwards to keep it interesting.

My colleague brought in his copy of the game and it made it much easier to imagine how we should be modeling it by having the game in front of us.

The Format

We used the Randori approach with four people participating for the whole session.

What We Learnt

• We tried out a couple of Javascript frameworks during the session – JSUnit and another one which is the testing framework used by the Prototype library. I’ve been using screw-unit on my current project and neither of the frameworks made test writing seem as fluent as it does when using screw-unit.
• IntelliJ is a way better editor for writing Javascript than Visual Studio is at the moment. It was really cool that we got auto completion when writing the code (although the auto complete function does currently give you the opportunity to call any method within the project’s Javascript files even if it’s not valid!)
• We had a copy of Javascript: The Good Parts with us which proved useful for showing us the right way to go when it comes to coding in javascript. Certainly trying to understand the meaning of the keyword ‘this’ was something that we didn’t find easy and I still don’t really understand what the ‘with‘ keyword does despite reading the definition several times.
• Modeling wise the approach we took provided a a much more interesting problem to solve – we were keen to avoid ending up doing a lot of string manipulation as we had on our java attempts at solving this problem. We got as far as telling a cell to remove itself from the board and were implementing the functionality for the cell to inform adjacent cells that it no longer existed.
• I hadn’t realised quite how easy jQuery has made it to do javascript work until this dojo. We were writing pure javascript which proved to be quite arduous although the code did read quite nicely once we got going. We’re planning to investigate whether jQuery would be useful for this type of coding or not.

For next time

• I won’t be able to make the next couple of dojos but the plan is to keep working on the Isola problem in the next session.
• I am also keen to try out Keith Braithwaite’s TDD exercise in one of our dojos, an idea which I came across from reading Gojko Adzic’s blog entry about the Software Craftsmanship Conference held in London last week.

  Briefly, the idea is to try to keep things simple – implement everything inside our test and then extract it out into classes and methods when necessary. Small steps is the order of the day.

I was recently reading Brad Cross’ recent post about creating objects which are Good Citizens in code and he certainly nails one aspect of this with regards to ensuring that our objects are in a usable state post construction.

In OO design, an object is considered to be a good citizen if it is in a fully composed and usable state post-construction. This means that once the constructor exits, the class is ready to use – without the need to call additional setters or init() methods.

This is the main reason I find the C# object initializer syntax such a nightmare – it gets blatantly abused and you end up with half constructed objects all around the code base and you’re never sure where your next Null Object Exception is going to come from so you pepper the code with null checks to try and avoid them.

Apart from this though I think another important aspect of an object being a good citizen is that when it makes use of other objects it does so in the way that object would expect it to.

For example I wouldn’t expect object A to call object B and pass in null as one of its parameters. When we’re not on the edges of our bounded context then I think it’s reasonable for objects to trust each other and assume that they will call each other in a non-evil way.

In a brief discussion with Dave about this he suggested that we might have different expectations of what makes a good citizen depending on the context in which we are using them.

For example, in our production code a good citizen wouldn’t try to break encapsulation of another object by using reflection – it should tell the object what to do rather than taking data our of it.

In test code though it may be perfectly acceptable for us to make use of reflection to check the state of an object after we have performed an operation on it.

Dan North and Aslak Hellesoy have written up a more stringent list of what makes a good citizen on the Pico Container website – I agree with the majority of them although I’d question whether every object should have an equals method on it unless its’ actually used and I’m still undecided about whether objects should fail on construction if passed bad data.

Either way, it’s definitely good to consider these types of things when writing code.

One of the problems we can encounter when using partials throughout our views is how we should create the model needed for those partials.

The approach that we have been following is to have the partial/child model on the parent model and then just call the appropriate method where we create the partial.

e.g.

public class ParentModel 
{
	public string Property1 {get;set;}
	public ChildModel ChildModel { get;set; }
}
 
public class ChildModel
{
	public string Property1 {get;set;}
}

We have sometimes run into the problem where the data in the ChildModel is being populated from the ParentModel (due to it also being needed there) leading to data duplication.

1
2
3
4
5
6

ParentModel parentModel = new ParentModel();
parentModel.Property1 = "value1"
parentModel.ChildModel = new ChildModel 
						{	
							Property1 = parentModel.Property1;
					  	}

Now the other problem with this is that we are relying on line 2 being executed before line 3 – we have created an order dependency in our code for no gain!

We are following a convention of having minimal logic in our views which means that we want to avoid creating the ChildModel in our view, meaning that we now have a problem to solve.

A cool approach which Dave introduced me to makes use of the Adaptor pattern to solve the problem.

We would adjust the ParentModel like so:

public class ParentModel
{
	public IChildModel { get { return new ChildModelAdaptor(this); }}
}

We then just delegate the calls to the ParentModel and drive the ChildModel to become an interface since it no longer needs to be a class.

public interface ChildModel
{
	string Property1 {get;set;}
}

public class ChildModelAdaptor : IChildModel 
{
	private ParentModel parentModel;
 
	public ChildModelAdaptor(ParentModel parentModel)
	{
		this.parentModel = parentModel;
	}
 
	public string Property1
	{		
		get { return parentModel.Property1; }
	}
}

If the data on the ChildModel is completely independent of the ParentModel then I would probably just create the model like before.

If the data on the ChildModel is a combination of data from the ParentModel and other classes then I would pass in those other classes in the constructor of the adaptor.

As we know with software development with pretty much every decision we make or technology we choose there is a trade off that goes with making this choice as compared with choosing an alternative.

I first learnt this when working with Ade a couple of years ago and while I know it to be true, I had come to believe that some practices are just non-negotiable and we should look to apply them judiciously wherever possible.

Various conversations have made me come to the realisation that not everyone believes this and that there are trade offs being made by following or not following these practices.

Domain Driven Design Ubiquitous Language

I consider this approach to writing software to be absolutely key to ensuring that the code base is easy to navigate around for newcomers and indeed to anyone who has to read the code after we have written it.

The trade off we are making here is that sometimes we will end up writing more code in designing our code around the language of the business rather than choosing a solution which may be technically easier to implement but less expressive.

To take a simple example of this in action, consider car insurance.

As a customer I would provide the insurer with details about my car, where I live and so on. This information would lead to me being provided with a Quote. Should I then decide to buy that Quote it would become a Policy. There is clearly quite an important difference between the two terms but in terms of data, maybe 75% is the same across both concepts.

If we decide to implement the language of the business in our code then we may end up creating a new object and copying a lot of data across from the old one.

The benefit we get from doing this is that the code is more expressive and describes the business process more accurately.

Interacting with other systems

My thoughts when it comes to using data from other systems is that we should look to keep interaction with the other system in one place – inside the anti corruption layer.

The benefit of doing this is that we keep control over our model and similar (but not exactly the same) concepts from other systems don’t creep into our application and lead to confusion around our domain model.

The disadvantage is that we may end up writing a lot of mapping code depending on how closely the other systems’ models are to our own. This code tends to be extremely tedious to write and difficult to test in a way that doesn’t involved re-creating most of the production code logic in our tests to create our expectations.

Object Oriented Programming

I have had the opportunity recently to work with several people who really know how to write code in this way and I’ve found it to be the most effective way to manage complexity in code that I’ve come across so far.

I’ve a long way to go before I’ve mastered OOP, but I try to follow the SOLID principles as much as possible – keeping classes small, behaviour with data and so on. – and I think it helps to make code much easier to understand and indeed change.

Now the trade off is that it is much harder to write code in this way than to just write procedural code and create anaemic objects which just have getters and setters on them. It also requires much more thinking – we have to think where to put behaviour, how to name new classes and so on.

Therefore I could easily see an argument that it’s quicker to write code procedurally than in an object oriented way. If we take this approach though we have to be prepared for the time we lose later on when it comes to trying to change the code that we were able to write so quickly before – it will probably take much longer now.

In Summary

I still believe that there is a lot of value in these approaches but it’s always good to know what alternative approach is being discarded by choosing a particular approach.

That way we can make more informed decisions.

I recently started playing around with Scott Bellware’s Spec-Unit and Aaron’s Jensen’s MSpec, two frameworks which both provide a way of writing Context/Spec style tests/specifications.

What I particularly like about this approach to writing tests is that we can divide assertions into specific blocks and have them all evaluated even if an earlier one fails.

NUnit is our testing tool of choice at the moment and we wanted to try and find a way to test the mapping between the domain and service layers of the application.

Testing in the normal way was resulting in a test that was absolutely massive and a bit of a nightmare to debug when something changed.

Luckily Dave came up with the idea of using the TestFixtureSetUp attribute on a method which would setup the test data and then call the appropriate method on the object under test.

We could then have smaller tests which asserted various parts of the mapping.

[TestFixture]
public class FooAdaptorTest 
{
	private Foo foo;
	private FooMessage fooMessage;
 
	[TestFixtureSetUp]
	public void GivenWeTransformAFoo()
	{
		foo = new Foo { Bar = "bar", Baz = "baz" };
		fooMessage = new FooAdaptor().MapFrom(foo);	
	}
 
	[Test]
	public void ShouldMapBar() 
	{
		Assert.AreEqual(foo.Bar, fooMessage.Bar);	
	}
 
	[Test]
	public void ShouldMapBaz() 
	{
		Assert.AreEqual(foo.Baz, fooMessage.Baz);		
	}
}

Of course this is a very simple example, and in a real example we would test more than just one property per test.

The Setup method does get pretty big depending on how much mapping needs to be done but it seems a reasonable trade off for the increased readability we get in the smaller size of each of the tests.

I know this isn’t the normal way of using NUnit but I think it’s cool to try and think outside the normal approach to find something that works better for us.