Mark Needham

Thoughts on Software Development

Archive for the ‘OOP’ Category

OOP: Behavioural and Structural constraints

with one comment

A few months ago I wrote a post describing how we should test the behaviour of code rather than the implementation whereby we would write tests against the public API of an object rather than exposing other internal data of the object and testing against that directly.

While I still think this is a useful way of testing code I didn’t really have a good definition for what makes that a test of an object’s behaviour.

I’ve been reading through James Odell’s ‘Advanced Object-Oriented Analysis and Design Using UML‘ and he describes it like so:

Behavioural constraints limit the way object state changes may occur

In Meilir Page-Jones language I think this would describe informative and imperative messages:

  • Informative – a message telling an object about something that happened in the past.
  • Imperative – a message telling an object to take some action on itself.

Both of these types of messages change the state of the object so in C# or Java these would be the public methods on an object that clients interact with.

That seems to describe the way that we would test the object. These would be the methods that we’d call in our test.

Odell goes on to describe structural constraints:

Structural constraints limit the way objects associate with each other, that is, they restrict object state.

This seems close to an interrogative message:

  • Interrogative – a message asking an object to reveal something about itself.

This would seem closer to the way that we would verify whether the object’s state changed as expected. We’re querying the object through the structural constraints that have been setup.

I can think of two main reasons why this approach is more effective than just testing directly against the internals of an object:

  • It ensures we’re testing something useful otherwise we might be writing tests on our code for a scenario that will never happen.
  • We have a better idea of when we’ve finished writing our tests since we know when we’ve tested all the behaviour.

Written by Mark Needham

December 31st, 2009 at 4:08 pm

Posted in OOP

Tagged with

OO with a bit of functional mixed in

with 2 comments

From my experiences playing around with F# and doing a bit of functional C# I’m beginning to think that the combination of functional and object oriented programming actually results in code which I think is more expressive and easy to work with than code written only with an object oriented approach in mind.

I’m also finding it much more fun to write code this way!

In a recent post Dean Wampler questions whether the supremacy of object oriented programming is over before going on to suggest that the future is probably going to be a mix of functional programming and object oriented programming.

I agree with his conclusion but there are some things Dean talks about which I don’t really understand:

The problem is that there is never a stable, clear object model in applications any more. What constitutes a BankAccount or Customer or whatever is fluid. It changes with each iteration. It’s different from one subsystem to another even within the same iteration! I see a lot of misfit object models that try to be all things to all people, so they are bloated and the teams that own them can’t be agile. The other extreme is “balkanization”, where each subsystem has its own model. We tend to think the latter case is bad. However, is lean and mean, but non-standard, worse than bloated, yet standardized?

I don’t think an object model needs to be stable – for me the whole point is to iterate it until we get something that fits the domain that we’re working in.

I’m not sure who thinks it’s bad for each subsystem to have its own model – this is certainly an approach that I think is quite useful. Having the same model across different subsystems makes our life significantly more difficult. There are several solutions for this outlined in Domain Driven Design.

Dean goes on to suggest that in a lot of applications data is just data and that having that data wrapped in objects doesn’t add much value.

I’ve worked on some projects which took that approach and I found the opposite to be true – if we have some data in an application it is very likely that there is going to be some sort of behaviour associated to it, meaning that it more than likely represents some concept in the business domain. I find it much easier to communicate with team mates about domain concepts if they’re represented explicitly as an object instead of just as a hash map of data for example.

Creating objects also helps manage the complexity by hiding information and from my experience it’s much easier to make changes in our code base when we’ve managed data & behaviour in this manner.

I think there is still a place for the functional programming approach though. Functional collection parameters for example are an excellent way to reduce accidental complexity in our code and removing useless state from our applications when performing operations on collections.

I don’t think using this type of approach to coding necessarily means that we need to expose the state of our objects though – we can still make use of these language features within our objects.

The most interesting thing for me about using this approach to some areas areas of coding when using C# is that you do need to change your mindset about how to solve a problem.

I typically solve problems with a procedural mindset where you just consider the next step you need to take sequentially to solve the problem. This can end up leading to quite verbose solutions.

The functional mindset seems to be more about considering the problem as a whole and then working out how we can simplify that problem from the outside in which is a bit of a paradigm shift. I don’t think I’ve completely made but it can certainly lead to solutions which are much easier to understand.

The other idea of functional programming that I’ve been experimenting with is that of trying to keep objects as immutable as possible. This pretty much means that every operation that I perform on an object which would previously mutate the object now returns a new instance of it.

This is much easier in F# than in C# where you end up writing quite a lot of extra code to make that possible and can be a bit confusing if you’re not used to that approach.

Sadek Drobi did a presentation at QCon London where he spoke more about taking a functional programming approach on a C# project and while he’s gone further than I have with the functional approach my current thinking is that we should model our domain and manage complexity with objects but when it comes to solving problems within those objects which are more algorithmic in nature the functional approach works better.

Written by Mark Needham

April 25th, 2009 at 11:14 am

Posted in OOP

Tagged with ,

QTB: Lean Times Require Lean Thinking

with 4 comments

I went to watch the latest ThoughtWorks Quarterly Technology Briefing on Tuesday, which was presented by my colleague Jason Yip and Paul Heaton, titled ‘Lean Times Require Lean Thinking

I’ve been reading quite a bit of lean related material lately but I thought it would be interesting to hear about it directly from the perspective of two people who have been involved with applying the concepts in organisations.

What did I learn?

  • It was pointed out that lean thinking is particularly relevant at the moment with the global financial crisis requiring organisations to come up with more effective ways of operating with little cash at their disposal. Toyota of course derived the Toyota Production System when they were in big trouble and needed to find a way out of their own financial crisis in the 1950s.
  • Lean is not just about manufacturing, it is being applied in many other industries as well. Paul pointed out that KMT are introducing it to the service side of many organisations. I think it is a different challenge introducing it into software development and while the Poppendiecks have written some excellent material on lean software development, there is still more for us to learn about how to do this successfully.
  • Although I’ve read quite a bit of material about lean I’ve never been convinced with the normal definition that I hear of lean in that ‘it’s about reducing waste’ but I didn’t have a better definition until Jason came up with ‘it’s about engaging everyone to solve problems‘. It does still feel a bit generic but I like it better than the other definition.
  • The most interesting part of the presentation for me was when Jason spoke about the different types of waste in lean in terms of software development:
    • Extra features (Over Production)
    • Delays (Wait and Queue) e.g. waiting for business sign off of stories
    • Hand-Offs (Internal Transport) e.g. passing work onto someone else
    • Re-learning (Over Processing) e.g. the same problems coming back when we have already previously learn about them. The first time we find a problem that counts as learning.
    • Partially done work (Inventory) – e.g. work requiring late integration which hasn’t been done yet. At an extreme I think this could be taken to mean any work which isn’t in production since it is only when we put something into production that the value from it is realised.
    • Task switching (Motion) – e.g. doing several projects at the same time. Here we end up with the problem that all of these projects are delivered late. Jason pointed out that just because people are busy doesn’t necessarily mean they are adding value.
    • Defects
    • Unused Employee Creativity

    The book ‘Learning to See‘ was suggested as a particularly useful one for learning how to identify waste.

  • There was mention of set based concurrent engineering which Brad Cross has an excellent post about. The idea is that when there is doubt about the best solution to a problem we pursue several different options at the same time before deciding on the best option at the last responsible moment.
  • Jason spoke about the difference between authority focus and responsibility focus, the latter being a more lean approach where we focus on ‘What is the right thing to do?’ and ‘How can I help?’ rather than the far more common approach I have noticed of ‘Whose job is this?’ and ‘Not my problem’. If we can get the responsibility focus going then suddenly the working environment becomes much more pleasant. Related to this I quite liked Liz Keogh’s recent post where she talks about rephrasing the language we use when talking about problems to avoid the blame culture.
  • Value streaming was also mentioned with relation to how our goal is to find added value for our customer and that most organisations only achieve around 20% of value added activity in their value streams. A comment which really stood out for me was how ‘no problem is a problem‘ in lean thinking. People like to hear good news and you can often be referred to as being negative when you point out problems. In lean we recognise there are going to be problems and get these raised and sorted out as soon as possible.

Written by Mark Needham

March 25th, 2009 at 12:36 am

Posted in OOP,QTB,Software Development

Tagged with , ,

OO: Reducing the cost of…lots of stuff!

with 4 comments

I’ve been working in the world of professional software development for a few years now and pretty much take it as a given that the best way to write code which is easy for other people to understand and work with is to write that code in an object oriented way.

Not everyone agrees with this approach of course and I’ve been told on occasions that I’m ‘over object orienting’ (is that even a word?) solutions. However, I think there are big advantages to be had from following an OO approach and I thought I’d explore these here.

Writing code in an object oriented way provides a way for us to manage complexity in an application. There always seems to be some degree of complexity, even in simple looking problems, so it makes sense to look for ways to mitigate that.

I think it’s fair to say that it is easier to write code in a procedural or quasi procedural/object oriented way whereby we tend to use ‘objects’ as data containers which we can shove data into and then take data out to use wherever we need to, and to start with we really don’t see any ill effects from doing this – the application still does what it’s supposed to, our acceptance tests pass and we chalk up our story points.

Then comes the time when we need to make changes to that code, and those times keep coming – a quote from Toby Young’s presentation at QCon London has him suggesting the following:

92% of cost is maintaining/supporting/upgrading existing systems; only 8% on new stuff.

Given that type of data I think it makes sense for us to try and make it as easy as possible to make those changes.

From my experience we tend to get this ‘nightmare to change mix of object oriented and procedural code’ mainly due to violations of the law of demeter i.e. putting getters on our classes and from copious use of setters which leave our objects in an inconsistent state.

We can immediately get a lot of benefits by not doing this – by setting up our objects in their constructors and by telling objects what to do rather than asking for data from them and choosing what to do with that data elsewhere.

So what are these benefits?

Reduced cost of change

One example I came across lately was to do with the creation of models to use on our views – using the ASP.NET MVC framework.

The models were being assembled somewhat similarly to this:

var parentModel = new ParentModel
				  {
					ChildModel = new ChildModel
								 {
									Property1 = new OtherObject(SomeCollection(), parentModel.SomeOtherProperty);
								 }				
				  };

It starts off fairly harmless, using the object initializer syntax, but what if we decide to change Property1 to be say Property2 as happened to us?

If we had set this through the constructor then we would have only had to make the change in one place and then we could have moved on.

In actual fact it turned out that there were 4 places where we were setting Property1 – all of them from within the controller in a similar way to the above example.

After a bit of investigation I realised that only one of those cases was being tested even though the property was being constructed slightly differently in a couple of the places.

As Michael Feathers teaches us in Working Effectively with Legacy Code if we’re going to try and refactor code we need to ensure first of all that there is a test which covers that functionality so that if we mistake we are informed of it.

This took longer than I expected due to the fact that there was quite a bit of setup needed since the only place to test this was through the controller.

If we had followed an object oriented approach here then not only would these tests have been easier to write, but they would have been written in the first place and not got forgotten about in the mess of the controller.

In theory what was a very simple change ended up taking a few hours.

Code that is much easier to test

As I mentioned earlier when we code in an object oriented way it becomes much easier to test because the context that we need to consider in our tests is massively reduced.

In the above example we should be able to test whether of not Property1 was being set correctly directly from the ChildModel rather than having to test it from our controller. Unfortunately by having it set through a setter we can’t do this in a meaningful way.

The creation of ‘OtherObject’ should be done inside the ChildModel and we can pass in the other data into the constructor of the class and then call Property1 in our test to see whether or not we get the expected result. We might end up with a ChildModel that looks more like this:

public class ChildModel
{
	public ChildModel(IEnumerable<string> someCollection, string selectedValue)
	{
		this.someCollection = someCollection;
		this.selectedValue = selectedValue;
	}
 
	public SomeObject Property1
	{
		get 
		{
			return new SomeObject(someCollection, selectedValue);
		}
	}
}

I know the example is contrived but hopefully the idea that putting this type of logic leads to easier to test units of code is clear.

Less need to debug

Another truly annoying consequence of creating train wreck code is that you end up with null pointer/reference exceptions all over the place and it’s quite difficult to immediately tell which part of the train caused the problem.

Since it would take a long time to get that segment of code under test and identify the problem that way out comes the debugger so that we can find out what went wrong.

It might help solve the problem this time but unless we change our coding style to remove this type of problem from happening then it’s just as likely to happen again tomorrow and we’ll be back to square one.

I hate using the debugger – it takes a long time to step through code compared to a TDD cycle and once you’ve solved the problem there isn’t an executable example/test that you can run to ensure that it doesn’t make a reappearance.

If we can write our code in an object oriented fashion then we pretty much remove this problem and our time can be spent much more effectively adding real value to our application.

Written by Mark Needham

March 12th, 2009 at 4:04 am

Posted in OOP

Tagged with ,

OO: Micro Types

with 13 comments

Micro or Tiny types present an approach to coding which seems to divide opinion in my experience, from those who think it’s a brilliant idea to those who believe it’s static typing gone mad.

I fall into the former group.

So what is it?

The idea is fairly simple – all primitives and strings in our code are wrapped by a class, meaning that we never pass primitives around.

In essence Rule #3 of Jeff Bay’s Object Calisthenics.

As I mentioned on a previous post about wrapping dates, I was first introduced to the idea by Darren Hobbs as a way of making APIs easier for others to use.

In the world of Java method signatures of 3rd party libraries with minimal Javadoc documentation tend to read like so when you look at their method signatures in your chosen editor.

doSomething(string, string, string, string)

The parameter name is sometimes not available meaning that it is now almost impossible to work out what each of those strings is supposed to represent – guesswork becomes the way forward!

I noticed an even more subtle example when working on a project last year where there was a method to transfer money between accounts. It looked like a bit like this:

public void transferMoney(Account debitAccount, Account creditAccount) {
	// code
}

See how easy it would be to get those accounts the wrong way around and suddenly the money is going in the wrong direction!

I always had to look twice to make sure we were doing the right thing – it was quite confusing.

Using micro types we could solve this problem by wrapping account with a more specific class. The signature could potentially read like so:

public void transferMoney(DebitAccount debitAccount, CreditAccount creditAccount) {
	// code
}

And the confusion has been removed.

The cost of doing this is obviously that we need to write more code – for the above example maybe something like this:

public class DebitAccount {
	private Account debitAccount;
 
	public DebitAccount(Account debitAccount) {
		this.debitAccount = debitAccount;
	}
}

We’d then delegate the necessary method calls through to the underlying Account although we probably don’t need to expose as many methods as the normal account object would since we only care about it in this specific context.

I had the opportunity to work on a project led by Nick for a couple of months last year where we were micro typing everything and I quite enjoyed it although opinion was again split.

I felt it helped to keep behaviour and the data together and was constantly forcing you to open your mind to new abstractions.

The other argument against the approach is that you are creating objects which have no behaviour.

I find here that it depends what you classify as behaviour – for me if there is some logic around the way that a string is formatted when it is going to be displayed then that is behaviour and we should look to put that logic as close to the data as possible i.e. within the micro type.

On that project each object rendered itself into a ViewData container which we accessed from our views.

public class Micro {
	private string micro;
 
	public Micro(string micro) {
		this.micro = micro;
	}
 
	public void renderTo(ViewData viewData) {
		viewData.add(micro);
	}
}

If an object contained more than one piece of data it could then decide which bits needed to be rendered.

It’s certainly not for everyone but it’s an approach that I felt made coding much more enjoyable and code much easier to navigate.

Written by Mark Needham

March 10th, 2009 at 10:40 pm

Posted in OOP

Tagged with ,

OOP: What does an object’s responsibility entail?

with 9 comments

One of the interesting discussions I’ve been having recently with some colleagues is around where the responsibility lies for describing the representation of an object when it is to be used in another bounded context – e.g. on the user interface or in a call to another system.

I believe that an object should be responsible for deciding how its data is used rather than having another object reach into it, retrieve its data and then decide what to do with it.

Therefore if we had an object Foo whose data was needed for a service call to another system my favoured approach would be for Foo to populate the FooMessage with the required data.

public class Foo 
{
	private string bar;
 
	public Foo(string bar)
	{
		this.bar = bar;
	}
 
	public void Populate(IFooMessage fooMessage) 
	{
		fooMessage.Bar = bar;
	}
}
public interface IFooMessage 
{
	string Bar { get; set; }
}
public class FooMessage : IFooMessage
{
	public string Bar { get; set; }
}

The advantage of this approach is that Foo has kept control over its internal data, encapsulation has been preserved. Although we could just expose ‘Bar’ and make it possible to build the FooMessage from somewhere else, this violates Tell Don’t Ask and opens up the possibility that Foo’s internal data could be used elsewhere in the system outside of its control.

The question to be answered is whether or not it should be Foo’s responsibility to generate a representation of itself. In discussion about this it was suggested that Foo has more than one responsibility if we design the class as I have.

Uncle Bob’s definition of the Single Responsibility Principle (SRP) in Agile Software Development: Principles, Patterns and Principles describes it thus:

A class should have only one reason to change.

In this example Foo would need to change if there was a change to the way that it needed to be represented as an IFooMessage as well as for other changes not related to messaging. Foo is not dependent on a concrete class though, only an interface definition, so the coupling isn’t as tight as it might be.

It might just be my interpretation of SRP but it seems like there is a trade off to be made between ensuring encapsulation and SRP in this instance.

The other way to create a FooMessage is to create a mapper class which takes the data out of the Foo class and then creates the FooMessage for us.

We might end up with something like this:

public class FooMapper 
{
	public FooMessage ConvertToMessage(Foo foo) 
	{
		return new FooMessage { Bar = foo.Bar; }
	}
}

Whereby Foo needs to expose Bar as a property in order to allow this mapping to be done.

This is somewhat similar to the way that NHibernate handles the persistence and loading of objects for us – unless we use the Active Record pattern an object is not responsible for saving/loading itself.

What I don’t like about this approach is that it doesn’t strike me as being particularly object oriented – in fact the mapper class would be an example of an agent noun class.

A cleaner solution which allows us to keep encapsulation in tact would be to make use of reflection to build the FooMessage from our mapper, probably by creating private properties on Foo as they are easier to reflect on than fields. The downside to the reflection approach is that code written in this way is probably more difficult to understand.

I know I’ve oversimplified the problem with my example but ignoring that, where should this type of code go or do we choose to make a trade off between the two approaches and pick which one best suits our situation?

Written by Mark Needham

February 9th, 2009 at 4:52 pm

Posted in OOP

Tagged with

Similarities between Domain Driven Design & Object Oriented Programming

with 3 comments

At the Alt.NET UK Conference which I attended over the weekend it occurred to me while listening to some of the discussions on Domain Driven Design that a lot of the ideas in DDD are actually very similar to those being practiced in Object Oriented Programming and related best practices.

The similarities

Anaemic Domain Model/Law of Demeter

There was quite a bit of discussion in the session about anaemic domain models.

An anaemic domain model is one where a lot of the objects are merely data holders and do not actually have any behaviour inside them. While it has a fancy name, in OO terms this problem materialises due to our failure to adhere to the Law of Demeter.

My colleague Dan Manges has a brilliant post describing this principle but a tell tale sign is that if you see code like the following in your code base then you’re probably breaking it.

1
object.GetSomething().GetSomethingElse().GetSomethingElse()

This is often referred to as train wreck code and comes from breaking the idea of Tell Don’t Ask. In essence we should not be asking an object for its data and then performing operations on that data, we should be telling the object what we want it to do.

Side Effect Free Functions/Command Query Separation

DDD talks about side effect free functions which are described as follows:

An operation that computes and returns a result without observable side effects

The developer calling an operation must understand its implementation and the implementation of all its delegations in order to anticipate the result.

My colleague Kris Kemper talks about a very similar OOP best practice called command query separation. From Martin Fowler’s description:

The really valuable idea in this principle is that it’s extremely handy if you can clearly separate methods that change state from those that don’t. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order.

It’s not exactly the same but they have a shared intention – helping to make the code read more intuitively so that we can understand what it does without having to read all of the implementation details.

Intention Revealing Interfaces/Meaningful Naming

Intention Revealing Interfaces describe a similar concept to Side Effect Free Functions although they address it slightly differently:

A design in which the names of classes, methods, and other elements convey both the original developer’s purpose in creating them and their value to a client developer.

If a developer must consider the implementation of a component in order to use it, the value of encapsulation is lost.

In OOP this would be described as using meaningful names as detailed in Uncle Bob’s Clean Code (my review).

Bounded Context/Clean Boundaries

DDD’s bounded context describes “The delimited applicability of a particular model” i.e. the context in which is is held valid.

This is quite closely related to the idea of clean boundaries in Clean Code where Uncle Bob states:

Code at the boundaries needs clear separation and tests that define expectations

In both cases we are creating an explicit separation of ‘our code’ from the outside world so to speak. We want to clearly define where ‘our world’ ends by defining the interfaces with which we interact with the outside world.

Anti Corruption Layer/Wrappers

The anti corruption layer in DDD is “an isolating layer to provide clients with functionality in terms of their own domain model.”

It is used to create a boundary for our bounded context so that the models of other systems we interact with doesn’t creep into our system.

This is implemented in OO using one of the wrapper patterns. Examples of these are the Facade, Adapter, or Gateway pattern which all solve the problem in slightly different ways.

The intention in all cases is to have one area of our code which calls 3rd party libraries and shields the rest of the code from them.

Domain Driven Design = Object Oriented Programming + Ubiquitous Language?

While talking through some of these ideas I started to come to the conclusion that maybe the ideas that DDD describe are in fact very similar to those that OOP originally set out to describe.

The bit that DDD gives us which has perhaps been forgotten in OOP over time is describing the interactions in our systems in terms of the business problem which we are trying to solve i.e. the Ubiquitous Language.

From Wikipedia’s Object Oriented Programming entry:

OOP can be used to translate from real-world phenomena to program elements (and vice versa). OOP was even invented for the purpose of physical modeling in the Simula-67 programming language.

The second idea of physical modeling seems to have got lost somewhere along the way and we often end up with code that describes a problem at a very low level. Instead of describing a business process we describe the technical solution to it. You can be writing OO code and still not have your objects representing the terms that the business uses.

There are some things that DDD has certainly made clearer than OOP has managed. Certainly the first part of the book which talks about building a business driven Domain Model is something which we don’t pay enough attention to when using OOP.

For me personally before I read the concepts of DDD I would derive a model that I thought worked and then rarely go back and re-look at it to see if it was actually accurate. Reading DDD has made me aware that this is vital otherwise you eventually end up translating between what the code says and what the business says.

Ideas around maintaining model integrity are also an area I don’t think would necessarily be covered in OOP although some of the implementations use OOP ideas so they are not that dissimilar.

Why the dismissal of DDD?

The reason I decided to explore the similarities between these two concepts wasn’t to dismiss Domain Driven Design – I think the framework it has given us for describing good software design is very useful.

Clearly I have not mapped every single DDD concept to an equivalent in OOP. I think DDD has given a name or term to some things that we may just take for granted in OOP. Certainly the DDD ideas expressed around the design of our model are all good OOP techniques that may not be explicitly stated anywhere.

I wanted to point out these similarities as I feel it can help to reduce the fear of adopting a new concept if we know it has some things in common with what we already know – if a developer knows how to write OO code and knows design concepts very well then the likelihood is that the leap to DDD will not actually be that great.

It would be really good if we could get to the stage where when we teach the concepts of OOP we can do so in a way that emphasises that the objects we create should be closely linked to the business domain and are not just arbitrary choices made by the developers on the team.

Maybe the greatest thing about DDD is that it has brought all these ideas together in one place and made them more visible to practitioners.

I am very interested in how different things overlap, what we can learn from these intersections and what things they have in common. It’s not about the name of the concept for me, but learning what the best way to deliver software and then to maintain that software after it has been delivered.

Written by Mark Needham

September 20th, 2008 at 1:12 pm