Mike's Blog

Refactoring Legacy Code

noreply@blogger.com (Michael Wagg) — Fri, 11 Jun 2010 13:33:00 +0000

The last few days I've been looking at some legacy code with an aim of bringing it under test and beginning refactoring. There has been plenty written about this (especially the Michael Feathers book Working Effectively with Legacy Code) but I thought it would be worthwhile writing about some of the techniques I have used as a refresher of how to approach these kind of problems.

Have a clear goal

Probably the most important thing to have when you begin refactoring legacy code is a well defined goal. Without this you can find yourself aimlessly tidying up and moving around code and not actually making things any better. Our gut often tells us that a piece of code is just bad, but by identifying a specific problem we have working with the code day to day we give ourselves more chance of success.

Specify don't verify

The same rules apply to tests here as they do in a greenfield project. Our aim is not to test the code, but to produce an artifact that describes what it does. We should focus on the behaviour of the area we are touching rather than testing specific existing classes/methods. The fact we get a nice set of regression tests is a happy side effect.

Make sure the tests you write actually prove what they say

The red in red-green-refactor is important because it proves our test before we implement the code. When the code already exists it's easy to just write the tests and move on without verifying them first. A nice simple way to achieve this is to comment out the code you want to test, write your test, watch it fail and then uncomment just enough code to make it pass. This is sometimes easier said than done but the general approach is useful.

Avoid the amount of change snowballing by extracting complexity

A common problem with refactoring legacy code is that to make one small change requires many other changes which in turn require even more changes.

For example when following the approach above we found that in order to pass the test for one small piece of behaviour we had to uncomment a call to a private method which had multiple paths. Now either we comment out the bits of that method we don't need, or we immediately add tests for the other paths, neither of which are ideal. Instead we extracted the private method into a new class and stuck an interface on it. Now we can use dependency injection to supply a fake version and do interaction testing to make sure it is called correctly.

At some point later we then proceed to put the newly extracted type under test having gained more knowledge of it's purpose from the earlier tests we have written for the code that consumes it.

Refactor once you gain insight

The previous technique allows us to put off the testing the extra complex stuff until later. But it is only really advisable to keep doing this if you have a nice boundary which tells you when to stop (which brings us back to having a clear goal).

Following this approach we tend to end up extracting quite a few types, some of which do a small amount of work and others which decide which work should be done. Now while single responsibility is all good and these types tend to do one very specific thing, this approach tends to result in going too far and so it should only be a temporary situation. For example we often end up with a big separation of data and functionality which is not very OO but is a side effect of breaking down large legacy classes with multiple responsibilities.

Hopefully by extracting, giving the new interfaces appropriate name and then bringing the extracted code under test we now have a much better understanding of what it does. At this point we should stop and begin to think about what the design for this code should look like. It's here that we can begin to put data and behaviour back together into well designed objects.

Use "scratch" refactoring liberally

"Scratch" refactoring describes a process where by we refactor code with the sole aim of learning more about it. This is useful when we are really not sure where to start. We begin by simply trying a refactoring and seeing where it gets us. Once we have learned something useful, either about the code or about where that specific refactoring will take us, we rollback our change and do it for real. Hopefully you have a good source control system to help you with this (from recent experience I can tell you TFS is not a good source control system) but if not try using something like git locally to allow you to quickly to commit and track what you have done and then rollback very cheaply.

Write throwaway tests to help you

Sometimes you have so much code intertwined together that just breaking it down is going to require quite a lot of change even to support simple unit tests. Ideally we don't change anything we don't have under test we just move it about (using a tool like Resharper) until we get round to putting it under test. But if we can't make it testable without changing it we can get into trouble.

In these cases it is often useful to write some quick and dirty integration tests that prove that the behaviour is not changing as we work. These tests might have to do some nasty things to work and will probably involve hitting external resources so they are not something you are going to want to check in. But they will help you begin to add unit tests and so they are a good temporary solution.

One thing we have to be aware of is that our understanding of the behaviour of a portion of the system may be sketchy at first and so we have to be careful that as we learn more we make sure to capture this in our throwaway tests so we are still protected until we have appropriate unit tests.

Hopefully we should end up in a situation where we have a good suite of unit tests which lets us remove the quick and dirty tests.

Using Git as an SVN Client

noreply@blogger.com (Michael Wagg) — Fri, 29 Jan 2010 00:42:00 +0000

Git’s a pretty awesome source control system and I’ve been using it exclusively for quite a few months now. One of the things that has made this possible is the fact that git can be used with an svn repository. Git supports a workflow very different than he normal subversion one and for me at least I find it much more natural.

This post is a quick summary of the workflow I generally use.

Initially Getting the Code

The first thing you want to do is grab the code from the subversion repository. There is more than one way to do this depending on your circumstance. Firstly if the svn repository doesn’t have a long history or you don’t mind waiting around for a while you can clone the repository, which means the git repository will have the entire history of the original repository. You do this using this command:

git svn clone http://repository_server/repository_url local_folder_name

Cloning can take a long time so this is not always ideal if you want to start working with the code quickly. A clone effectively initialises a repository and then fetches the entire history. You can save time by doing the init manually and then fetching just some of the recent history. You do this by checking the subversion log and noting the revision number of how far back you want to go and then using the following commands (using revision 1234 as an example here):

git svn init http://repository_server/repository_url local_folder_name cd local_folder_name git svn fetch -r1234

This will cause the local git repository to have all the history from revision 1234 onwards.

Branch Per Feature

Initially your git repository will have one master branch. I generally keep the master branch as the one used to integrate changes from the subversion repository with my local copy. For the actual coding I create a new branch for each feature. Creating branches with git is nice and easy.

git branch feature_name

and switching between branches is just as easy

git checkout branch_name

Checking and Committing Changes

Once on the branch you develop your features as usual. Once thing I find with git is that I will commit far more often as I do not need to push these changes to the central repository immediately. The standard checkin process involves checking the current status of the branch, adding/removing files and adding changes the commit and then making actual commits. If you are not familiar with this standard workflow in git checkout out the git site.

First of all checking for any local changes is achieved using the following command:

git status

If you have changed files which are already tracked by git you must add these changes to the commit. There are a few ways to do this but I tend to use the following which adds all changes in tracked files.

git add -u

If you need to add new files or remove any existing files then you use:

git add file_path

git rm file_path

Finally to commit any changes you use the commit command:

git commit -m "comment"

Integrating Changes From the Subversion Repository

At some point you will want to get the changes from the subversion repository into your local copy. There are two steps to this. Firstly getting the changes from the server onto your master branch and secondly integrating those changes with your changes on the feature branch.

Firstly make sure you are on the master branch and then pull the changes in:

git checkout master git svn rebase

Now we need to integrate the svn changes with our feature branch. For this we switch to the feature branch and then execute a rebase. This rebase effectively removes any changes on the branch made since it was first created, merges the changes in from the master branch and then re-applies the branch changes on top. By applying our changes on top of the subversion changes we reflect the fact that our local commits have not been integrated with the remote repository and so we deal with any merge conflicts locally.

git checkout branch_name git rebase master

At this point you may get conflicts between the local and remote changes. You resolve this in the standard way by fixing the code locally, adding your fixes (git add -u) and then continuing the rebase (git rebase --continue), again you should look at the git documentation to get more details on this.

Committing Local Changes to the SVN Repository

Once you have reached a point where you want to push your changes to the central repository you first pull in any subversion changes as described above, then you merge your branch changes into the master and finally you push the changes in master back to the original repository. Merging form the branch to master is as simple as switching back to the master branch and executing a merge. Assuming you have already pulled all subversion changes into the master branch and rebased the feature branch based on that you should not have any merge issues,

git checkout master git merge branch_name

The last step is to push the now merged changes back to the repository. Again this is nice and simple with git and requires only one command.

git svn dcommit

That covers the basic workflow which I am currently following for using git with svn. There are of course plenty of very cool things git does that makes life much easier for me as a developer and hopefully I can cover those in another post soon.

What does the M in MVC actually mean?

noreply@blogger.com (Michael Wagg) — Mon, 12 Oct 2009 18:20:00 +0000

I was quite lucky when I first started my development career to be involved in a project where I spent a lot of time looking into presentation patterns. In retrospect this was very good experience which taught me a lot of the basics which I build on today.

There were two things in particular which I got out of it. Firstly I got to learn the patterns outside of any specific framework and secondly I had it drilled into me that the presentation part of the system is never the entire system.

The second point is quite important as often you can get into a mindset of “today I’m building an MVC application” when in reality you are putting an MVC presentation layer onto your application, even if that application is very simple. The importance of remembering this is relative to the complexity of the system but it’s a good way to think.

It’s great that Microsoft finally released an MVC framework for .Net but I can remember having a conversation (I think with Tim) in which we discussed if MVC just meant that all the poorly written code behind logic would become poorly written Controller code. Unfortunately this seems to be coming true.

The problem seems to me that a lot of people are confused about exactly what the Model in MVC means, or at least they are confused about what it’s practical implementation is. I’ve seen quite a few different definitions of what it is and what it isn’t and this makes things very confusing. It’s not that these definitions are wrong, it’s that they are often pushed as the definitive description of what the Model should be. In reality, at least in my opinion, the answer to the question is the same as the answer to most good questions in software development, it depends.

In a very simple application the Model is the rest of the system. It’s a simple object model that's probably persisted directly to the database and which the view is bound to without any abstraction. This is the kind of app Ruby on Rails is really good at (and ASP.Net MVC is not so good at, at least not out of the box anyway). This is also the kind of app that most of the demos, blogs, books and speakers seem to show when talking about MVC and if this is what you’re doing it’s pretty hard to go wrong.

Unfortunately most apps I’ve seen are more complex than this. Not massively complex but enough so that this approach shows it’s weaknesses. The same general rules apply in these systems, keep logic out of the View, keep the Controller very thin (very very thin actually) and keep business logic in your domain model.

In these apps you probably have a fair amount of logic that is just presentation logic. You keep this out of the View because that results in very messy code but if you put it in your Controller then it starts to become fat. You could push it into the Model but that means you are starting to mix presentation and business logic. It’s trying to resolve this kind of issue that tends to be the downfall of most of the apps using MVC I’ve seen.

In these situations the two lesson I talked about above become very useful. It’s good to step back from the ASP.Net MVC framework itself and just think in pure MVC terms. It’s also very important to remember that the MVC part is just the presentation stuff on top of the actual system. Solving these problems is always done by doing the right thing with your Model.

Like I said above the exact answer always depends on your situation but I generally find that your Model actually becomes a couple of models. Firstly your domain model sticks to containing business logic and remains the most important part of the system. But in addition to this adding a model specifically for the presentation layer is very useful. I think people often shy away from this because it feels like it adds more complexity but I find it often makes things much simpler.

A presentation specific model contains the information from the domain perfectly formatted for the View. This means all the logic that might have gone into the Controller to shape the data instead goes into the presentation model. Also any logic you might have been tempted to put in the View can be pulled into the Model. This also means you can use all of the cool features of MVC (model binders, using annotations for basic validation etc) without worryingly about polluting your domain model.

The only tricky part of this approach is mapping your domain model to your presentation model. There are plenty of different approaches to this and it really does depend on your context as to which one to use. Personally I stay away from using setters on my domain model so mapping for me is not about copying properties to properties but instead mapping incoming data to operations on an object.

This post is too long now so I should probably stop typing. The whole point of it was that the Model is the most important part. You should focus your efforts on getting this part of the system right for the context in which you are in and you should not restrict yourself to the specifics of the framework you are using when doing so.

Installing Cucumber on Windows

noreply@blogger.com (Michael Wagg) — Wed, 24 Jun 2009 20:11:00 +0000

I had a great time on Tuesday giving an introduction talk on Cucumber, the Ruby BDD test runner at a London .Net User Group meeting. I promised I'd get a post up with some help on getting Cucumber set up and so here it is.

Setting up basic Ruby and Cucumber

Setting Cucumber up on the standard version of Ruby is fairly straight forward.

First head to the Ruby site and grab the latest one click installer from the download page. During the install make sure you check the "Enable Ruby Gems" option.

Once Ruby is installed on your machine we use the Gems package manager to install Cucumber. Firstly it's a good idea to check your gems are up to date so open up a command prompt and type "gem update --system", followed by "gem update". Once that completes we can install Cucumber by typing "gem install cucumber win32console". The win32console gem give us nice colours in our console output.

To check everything is good type "cucumber --version" and Cucumber should give you it's version information.

Installing Watir

With the standard version of Ruby Cucumber we can't interact with any .Net code directly. But it is still useful to us. Watir is one of the best uses of it I've found.

Put simply Watir automates browsers and has a nice Ruby API. If you put Cucumber on top of it you have yourself a very readable DSL for driving acceptance tests for a website

Watir can be installed by using gems again, this time using the command "gem install watir".

On Windows this will let you automate Internet Explorer and Firefox, though you will need to install an extension for Firefox. You can get more details on this from the Watir installation page

Cucumber and IronRuby

Ok so far so good. But now we get to IronRuby. Now this is an awesome project as it's bringing Ruby into the .Net world but it is still relatively new and under heavy development. As a result of this at the moment it's a little bit more involved to get going and Cucumber seems to work purely based on the current wind direction. Having said that the guys are doing a great job with it and the pace of improvement has been impressive so I expect things to get much more stable very soon

William Green (aka hotgazpacho) has a good post describing what you need to do to get Cucumber and IronRuby working together so I'll send you there for the details. But to summarise you want to be using the latest version of IronRuby which involves grabbing the source from GitHub, compiling the IronRuby code and then using the IronRuby version of Gem to get cucumber.

Good luck!

Why I love TDD/BDD

noreply@blogger.com (Michael Wagg) — Mon, 01 Jun 2009 20:13:00 +0000

After watching Uncle Bob's presentation at RailsConf a couple of weeks ago I was reminded by one of the points he made of the reason I love TDD and more specifically BDD so much. Actually there are plenty of reasons I love it but one stands out above the rest as the main one.

Now this is something that plenty of people have already talked and blogged about before but I just wanted to get involved and say it myself.

TDD/BDD is great because it removes the fear from refactoring.

For me there is something that tends to be found in the best developers. Its not that they can always come up with the best design for every problem before they even touch the keyboard. Its not that they never write code that goes against the SOLID principles. It's not even that they have learnt every pattern in the book off by heart.

The best developers are those that continuously refine their code. They take something that is just a solution to the problem at hand and transform it into something which is clean and elegant. They craft a piece of code that is easily understandable by other developers and which can be easily maintained as the requirements of the system changes.

For me refactoring is the main technique I use when developing. I often describe my approach to it as 'aggressive refactoring', firstly because it sounds cools and secondly because it gets across how important I think it is. Refactoring lets me take my initial and often messy first stab at solving a problem and change it into something I can be proud of and which captures the insight I gain as I improve my understanding of the problem. If I just did what far too many of the developers I've met do and simply solved the problem the first way I could and then moved on, I'd leave behind me a trail of unmaintainable code.

To bring this post back to the subject of its title, what TDD and BDD give me is the safety net that tells me my code still does what I want it to do after I've refactored the hell out of it. This works just as well for code I wrote a minute ago as it does for code I wrote a year ago. In fact for any system that is going to last longer than five minutes the only way it can avoid becoming the unmaintainable mess that most legacy systems are is by being built in such a way as to support constant refactoring during its lifetime and that means having a good suite of tests or specs.

And so almost solely for that reason I love you TDD/BDD

The Information Expert Principle

noreply@blogger.com (Michael Wagg) — Tue, 26 May 2009 21:05:00 +0000

During a conversation I had today I was reminded of one of the first principles of Object Orientated design I was ever taught that really clicked with me. It's something I use daily subconsciously but I never seem to talk about much. After all of the talk around SOLID recently I thought it was worth putting a post together on it.

One of the most important parts of OO design (at least in my opinion) is deciding which object a particular responsibility belongs to. Its fairly safe to say that with the right objects and more importantly with the right responsibilities assigned to those objects you're well on your way to having a design which is easy to understand, maintain and extend.

A lot of the time knowing where a responsibility sits is simple developer intuition and we do it without thinking. But it's worth being able to put some reasoning behind those decisions so that we can apply those same reasons in the cases that are not so obvious. It's also worth having these principles because sometimes it's easy to fall into common traps when building complex software.

One of my current projects involves taking a set of loan requirements and calculating the cost of various loans on offer. This is a good example of the kind of problem in which we can be guided by the Information Expert principle.

I've seen variations of this problem pretty much everywhere I've worked and one of the common solutions is to create a class to represent the calculation involved. In our case lets call it the LoansCalculator class. This class takes a set of Loans and a LoanRequirement and asks each Loan for the relevant information which is used to calculate the results.

Now this approach is not evil in itself but it's probably not the best solution to the problem. For a start it's not great that the LoansCalculator has to ask the Loan for information about it's state. Tell, Dont Ask is another one of the great OO principles I try and stick to.

What's more important about the calculator approach though is that experience tells us that this approach doesn't age well. For example probably the most common problem I've seen occur is that a new Loan type comes along which has a different calculation. The developer dealing with this problem adds a LoanType enumeration to the Loan and a switch statement in the LoansCalculator and everything works just fine. Then the next new Loan type comes along and the next developer adds a value to the enumeration and extends the switch statement. Then yet another new Loan type comes along and before you know it we're in a mess.

If we we're to stop and think for a minute and consider the Information Expert principle we would probably come up with a different solution. Since the Loan has the information required to perform the calculation then it is the expert and so it makes sense to give it the responsibility of calculating the cost.

This is great firstly because now we don't have to expose the state of the Loan to anyone else. We tell the Loan to calculate it's cost based on the LoanRequirements and don't need to ask any of its details.

Secondly when a new Loan type comes along we can use the power of our OO language to solve the problem by applying polymorphism. We create derived class of Loan which encapsulates the new Loan type and calculation and the consuming code carries on as usual.

Personally I also find that this type of design is much easier to understand and thus maintain and it lets me use my OO know how to extend the system when required.

Of course as with all principles the Information Expert is not an absolute rule and does not apply in all situations. I find that using the Information Expert and Single Responsibility principles in conjunction with each other generally works well.

Craig Larman had a great example of this which I'm paraphrase here, mainly because I can't remember his exact example. We could say that the Loan class knows most about a specific instance of a loans details and so it is arguably an Information Expert when it comes to persisting a Loan. However if we consider SRP it probably makes more sense to have another class (or indeed a framework) deal with the persistence while our Loan class concentrates on encapsulating a loan.

So there you go. Information Expert seems like it's just stating the obvious thing that we all know as devs. But it is worth stepping back every now and again and justifying why we make these design decisions just to make sure that we really are doing the right thing.

Moving towards a leaner software development process

noreply@blogger.com (Michael Wagg) — Wed, 25 Mar 2009 20:37:00 +0000

Lately I've been spending a lot of time thinking about software development processes and how to move from doing a SCRUM style agile to a much leaner style of development. I'm very interested in this area because I believe we can deliver more value to the business by being able to release frequently and use the feedback that follows from that to steer us more accurately.

I was recently at QCON and caught an excellent talk by Kris Lander and Gus Power from Energized Work titled Turning on a sixpence - No excuses: Concept To Cash Every Week which really helped to solidify some of the ideas I've been having.

I have been meaning to put together a post on this for a while but I seem to always be too busy at the moment. So in the meantime I figured I'd get something up here by posting up the bullet points I jotted down on the tube a couple of weeks ago which were meant to be the start of an actual post. I then plan to expand on some of the points over the next few posts.

These points are the ideas and aims my ideal team would be following. I should also mention more than a few of them are pretty much stolen from the Energized Work talk as those guys summed them up so well.

So without any more delay here we go.

Focus on throughput
Deliver frequently at a predictable pace
Your wall should have sections for backlog, in progress, inventory and done
Done is live and making us money
Inventory is developed and tested with the money spent but not yet
earning us anything
Focus on small deliverable stories or chunks of work
Slice features up from the minimum deliverable amount to the full feature
Don't be afraid to put a partially complete feature (i.e. a feature that works but doesn't do everything initially specified) live as long as the business is happy
Use the feedback from live features to decide whether to continue to develop them or move onto new features
Use the inventory section as an indicator of how much we have completed but not yet live
The inventory is the indicator of when to go live, not the iteration
We always go live at least once an iteration, but we don't limit ourselves if our inventory indicates otherwise
Keep our iterations short, ideally weekly
Plan on demand. At the beginning of the iteration and then in short sessions during the iteration doing just enough to ensure we don't run out of work
Don't have too much in any one section of our wall to ensure our stream is manageable
Focus on going live from day one, bake quality in from the start. Don't separate testing from developing
Estimate technical debt even if it is not being fixed immediately. Make it visible to everyone

Testing isn't about tools

noreply@blogger.com (Michael Wagg) — Mon, 16 Feb 2009 19:50:00 +0000

Hemal has just blogged about Developers talking about testing and he makes some very good points on how the focus can get lost when people concentrate too much on tools.

We are currently focusing very strongly on 'baking in quality' to our process. This involves moving away from having a designated part of our iteration where the developers pass the system over to QA and instead to try and have each member of the team take responsibility for the quality of the system throughout the development process.

We are already very good at unit testing our code and so we began to look at other tools to automate the verification of the quality of what we were producing. As part of this process we looked and Fitnesse and Selenium, both very good tools when applied to the right problems.

One of the specific problems Hemal discusses is how Fitnesse and Selenium became the focus of testing. I specifically had an issue with the usage of Selenium, which while being a great tool for front end testing, is not the solution to all or even most testing problems. More specifically I felt that we had lost sight of exaclty how much value we could get out of plain old integration testing using NUnit.

While you can argue that Selenium tests all the way from the front to back end in the same way the end user will, in reality there are a number of issues with them. Test suites can quickly become expensive to maintain, running the tests is not as fast as other methods and there are certain situations which we just cannot test properly using this kind of tool.

Contrasting this with just writing some integration tests in C# using NUnit we have a much more powerful and flexible language which produces tests which are more maintainable and more likely to be understood by future developers.

My point isn't that NUnit is a better testing tool than Selenium, but as Hemal points out that we have to be careful to keep our eye on what we are testing and choose the appropiate method at that time.

Its not what you are but what you can do that counts

noreply@blogger.com (Michael Wagg) — Mon, 02 Feb 2009 20:02:00 +0000

When I was first taught about inheritance I was shown an example similar to the following.

We can categorise Cows and Horses as both being types of Animals. We can represent this by having a base class Animal and two derived classes Cow and Horse.

Now we can create an abstract method on Animal called MakeNoise() and then the derived classes implement their own versions to make the appropriate noise.

public abstract class Animal
{
    public abstract void MakeNoise();
}

public class Cow : Animal
{
    public override void MakeNoise()
    {
        Console.WriteLine("Moo");
    }
}

public class Horse : Animal
{
    public override void MakeNoise()
    {
        Console.WriteLine("Neigh");
    }
}

This example is ok for showing some of the mechanics of inheritance but it can be misleading in terms of how we use inheritance for modelling.

I was lucky in that in my first real job after university I worked with people who really knew what they were doing and were eager to share that knowledge.

One of the first things I was taught was to think about objects more in terms of what they do than what they are. So if we take the example of the Horse from above rather than consider it as an Animal, we may instead model the fact that it can pull a cart as that is something we are more interested in.

We may also consider a Tractor object which can also pull a cart but is definitely not an Animal. So rather than try to model the Horse and the Tractor using inheritance we would probably instead create an interface ICanPullCart. Now if both objects implement the interface we don’t need a common base class which is great because it means our classes support more flexibility.

Now there are plenty of discussions on the web on inheritance vs interfaces and on favouring composition over inheritance and I don’t want to repeat too much of it here. I personally generally prefer composition as a way of creating useful objects but that doesn’t mean ruling out inheritance when it makes sense. A lot of these arguments centre around creating frameworks but I’m more interested in modelling a domain where I believe what something can do is more important than what it derives from.

So the reason I’m posting about this now is that I’m spending more and more of my time playing around with Ruby and I’m really interested in how these ideas apply in a dynamic language. Specifically I’m talking about Duck Typing which is nicely explained by the following phrase:

If it walks like a duck and quacks like a duck, I would call it a duck.

This can seem strange when you have been working in a statically typed language like C# for a while. In Ruby we don’t care that an object is an Animal, a Horse or a Tractor. All that matters is that the object can pull a cart. While in C# we mark the class with an interface in Ruby the fact that the object supports the method is enough.

This becomes even more interesting if you think in purer OO terms of objects sending message to other objects where we only care about what messages an object can understand.

While none of this may seem hugely ground breaking stuff I’ve found it interesting in the last couple of weeks. Shifting my focus from thinking about what something derives from to what roles it can play gave me a greater insight into modelling. In the same way shifting from thinking about interfaces, which are an implementation detail of statically types languages, to a purer OO model of objects and message has again helped me to think a little better about the systems I am building.

Keeping the most important part of the application out of the Controller

noreply@blogger.com (Michael Wagg) — Sun, 25 Jan 2009 19:39:00 +0000

In my last couple of posts I’ve been focussing on keeping View specific logic out of the Controller. Now I’d like to look at the other side of the Controller and talk about why we should keep Model or domain logic out of it.

Back in 2007 Jeffrey Palermo wrote a post entitled Focus on the core: the most important part of the application that really changed how I viewed different parts of an application. In any system beyond a basic level of complexity there is a core portion of code that represents the key domain logic that is valuable to the business. There is also likely to be other logic, such as presentation or persistence which exists in order for the system to be functional. If we look at the presentation code as an example, this is likely change far more often than the core code and so it is good practice to keep these two separated so that changing the presentation does not require rewriting the core.

If we are using MVC or MVP then our Controllers (or Presenters) are very much part of the presentation layer. They are also the part of that layer that interacts with the core business logic layer and because of that it is easy to let business logic creep into them. Controllers should be responsible for coordinating the interactions of the user of the system with its core, deciding what action to take in response to input but not actually doing any of the work itself.

Often some operation requires a complex interaction with the domain such as getting an entity from a repository, processing it with a domain service, passing it to other entities which must also be retrieved from somewhere and finally persisting any changes. It is tempting to make the Controller take each of these steps itself but we should ask ourselves if this amount of coordination is actually part of the presentation layer, or if we need to introduce a new component into our domain which the Controller can delegate to in order to achieve the desired outcome. Taking the second option means this set of logic now remains in the domain if we remove the presentation layer and swap it for another.

From my view there are two major reasons for taking this idea seriously. The first is about being realistic about how much value our presentation layer gives us and how often we will change it. If two business in the same area are both using the .Net platform then their presentation layers are likely to be very similar and it will be the differences in the domain that will give one the edge over the other. If a new presentation framework comes along then both may consider switching to using it, however the cost of this will depend on whether it requires rewriting just the presentation layer or an entire app rewrite because the business logic is in the presentation layer. The new platform may offer new features that can reduce costs for the business or given enough time the skill set of the market may move on such that not moving becomes expensive from a hiring perspective. Assuming that in an active and competitive business market both business will want to keep up they will both eventually have to make the switch and the one that can achieve this more easily has an advantage.

The second reason for keeping your Controllers clean from business logic concerns is to do with resource management. Most projects operate with a limited team of varying skill levels and ability. By adopting these approaches we inherently put more effort into building the domain and work on presenting the Controller with as simple an interface as possible. This means that the presentation layer is easier to write as it is doing much less work. However if we do not adopt this approach then the presentation layer becomes much more complex and that is where the effort is concentrated.

Front end coding skills tends to be easily transferable between businesses. For example it is currently very easy to find Asp.Net WebForm developers with a skill set that would allow them to begin writing a presentation layer that did not require building a domain. However it is much harder to find developers with domain specific knowledge for a given business or even a given industry. More often than not the most knowledgeable developers are the developers that have been with the business for a long time. It makes sense for a team made up of both types of developer to put the more experienced developers onto building the core part of the code that will outlive the current presentation framework. The remaining (and presumably cheaper) developers can then develop the presentation code, interacting with the simplified interface developed by the more knowledgeable developers.

I’d like to finish off by stealing some of Jeff's original post. Read his post and then think about your current project and think:

Take a step back and remove the screens. Remove the database. Is there any application left? Can you point to any business rules or domain concepts left in the application after the presentation and storage components are removed? In my experience, I've had to answer "no" more than once. This is absolutely the wrong way to develop software.

Managing Complexity with MVP and a Presentation Model

noreply@blogger.com (Michael Wagg) — Sun, 18 Jan 2009 16:30:00 +0000

In my last post I talked about the basics of the common presentation patterns. I’d now like to go a bit deeper on how these simple patterns alone do not work when dealing with complex presentation layers.

I’ve recently been doing work with ASP.Net WebForms, having previously been working on MVC projects. I don’t want to get technology specific in this post but what I’ll be talking about is based largely on my recent experience.

The Problem

So we are talking about a complex web application using the MVP model for the presentation layer. With MVP we have a general pattern that the View receives some input and passes a message onto the Controller (you could call this Controller or Presenter but I’m going to stick to Controller from now on). The Controller takes the message from the View, decides what action to take and then interacts with the Model appropriately. At this point the view then reflects any appropriate changes in the Model. Where things often get complex is in how the difference in the representation of the View and the Model are translated during this process.

Passive View has the View as a very simple component which exposes all its relevant control properties and contains no logic itself. The Controller updates and reads from the View directly as appropriate. For simple scenarios this approach can work well, however as things get more complex it becomes inappropriate.

The problem is that as the amount of logic required to translate between the Model and the View increases, the Controller grows and grows. This is made worse when there is more than just the simple display of information going on. For example you may have various properties of controls such as the visibility, border or colour being set based on the Model.

Now we have a component which has multiple responsibilities. Firstly it must interact with the domain. Then it must translate between how the Model represents the relevant information and how the View does. Finally it must actually update the View itself. Experience tells us that such a component will be hard to maintain.

In other parts of a complex system we would aim to refactor these responsibilities out. Ideally we want the Controller to just have the single responsibility of interacting with the domain, while other components handle the other concerns. If this idea is something unfamiliar to you then have a look at the Single Responsible Principle article from Uncle Bobs Principles of OOD.

The Supervising Controller pattern improves things somewhat in that it stipulates that the Controller should focus on its interactions with the Model. The View should handle the job of reflecting the changes itself. While this solves our problem as far as the Controller is concerned it still isn’t a great overall solution.

The problem now is that the View has all of the translation logic. Traditionally the technology used to implement a View is hard to test so putting the logic here may make it difficult to control the quality of it during new development or refactoring.

Also we could now say that the View has too many responsibilities as it is handling the translation between the different representations, as well as the technology specific concerns related to the UI platform being used. In a simple system this may not be such a problem, but remember we are talking about a complex UI here and we want to avoid having any particular component being too complex.

WebForms serves as a great example of the problems we have discussed. A page or control has the technology specific concern of the ASP.Net lifecycle. While this is not hugely complicated on its own, trying to handle this while also ensuring that the translation logic is implemented correctly can be tricky. Trying to do this in a way that keeps the code clean and understandable for new developers on the project can be very tricky. When the complexity of the translation logic gets really complicated, such as when it is applied differently based on different contexts as we had on our project, this quickly becomes unworkable. This is not picking on WebForms, we would have the same issue with any other UI platform.

So what’s the answer?

As always there is more than one way to solve a problem in software. But one thing that seems like an obvious solution is to introduce a new component into the mix to take on some of the responsibilities we are trying to manage.

We chose to introduce a new component based on the idea of a Presentation Model into our design. This is a component that exposes two interfaces geared towards the two different views its sits between.

On the one side is an interface that is geared towards the Model. The interface exposes properties and methods that accept ideas out of the Model with no regard for the View specific representation.

On the other side is an interface that contains exactly what the View needs including actual data and other values such as whether certain control should be visible or the colour they should be etc.

The Presentation Model itself then contains the logic to map between these two interfaces. A huge benefit of this design is that complex logic is now contained inside an object which can be tested very easily. Simple mapping is just a case of setting the relevant value on one side and asserting that the other side returns the correct value. For complex logic based on multiple values you can simply have a tests for each context which set the many input values and check they resolve correctly on the other side.

One other aspect of Presentation Model is that it works both ways. When the user has modified a value on the View, the Presentation Model takes the responsibility of mapping that change back to something that makes sense from the Models perspective. Because of this the Controller continues to maintain its focus on its interaction with the Model and does not become concerned with how the View works.

The last piece of using a Presentation Model is how the View gets and sets the values in the Presentation Model. The current method I have been using is to have the View copy all the values in to itself and vice-versa. While this is code contained in the View, it should simply be a case of copying values from one place to another. If you find for any reason you start to put logic in the View then that is an indicator that you have something else to factor out into the Presentation Model.

This approach has worked well when working with WebForms. When we reach the Load lifecycle stage we copy the current state of the View into the Presentation Model and when we reach the PreRender stage we copy the current state of the Presentation Model into the View. This has been great for removing any knowledge of the life cycle from the Controller.

Other points to consider

If you are considering implementing a Presentation Model in your designs then I would encourage you to treat my explanation of it as a very rough summary. There are several ways in which you can include a Presentation Model but vary how it implements its role and the approach I have outlined is probably not suitable for all situations.

One variation that I am interested in pursuing flips the relationship between the View and the Presentation Model. It does this by making the latter responsible for the synchronisation between the two. The View becomes a Passive View exposing an appropriate interface to its controls. The Presentation Model assumes a Presenter like approach setting and getting values on the View rather than exposing a View facing interface. This makes the View even thinner which is always a good thing in my book.

Another approach would be to incorporate data binding so that the relationship between the View and Presentation Model can be specified declaratively and repetitive code copying backwards and forwards is removed.

I’d be very interested in hearing any feedback on this approach and its variations. These ideas completely turned round a big part of the WebForms project I was working on but as always there is no single solution to all software development problems.

However the key point I’d like to finish this post with is that we should be looking at our designs constantly making sure that we are properly managing complexity. More importantly we must not be afraid to take existing patterns or designs and add to them in order to handle new responsibilities. Keeping each component in the design simple and focussed is the best way to ensure quality can be maintained throughout the codes lifetime.

Presentation patterns

noreply@blogger.com (Michael Wagg) — Sat, 10 Jan 2009 19:37:00 +0000

To kick off the few posts I’ll be doing on presentation patterns I’d like to quickly discuss the basics of the common ones. There are plenty of places on the web that discuss technology specific implementations of these patterns but think that it is important to also understand them without thinking about implementation.

I felt I really learnt the most about these patterns when I moved from doing them in a rich client environment with WinForms to the web with WebForms. I had to focus on the concepts behind what I knew and try and forget the specific implementation techniques.

Now as a disclaimer I don’t pretend to be an expert on everything UI related and I don’t intend this post to be all inclusive or definitive. But I do want to lay the foundation for some of the stuff I’d like to talk about in the next couple of posts.

View/Model Separation

Generally all presentation patterns have the concept of View/Model separation at their core. The idea is that the objects dealing with the domain should not be complicated by presentation concerns. This also means that you can in theory implement the views in a different technology without having to replace the core domain code.

The Model is often the most confusing part of the common patterns. The Model effectively includes any part of the system that is not presentation or infrastructure. In reality the Model simply means the portion of the domain that is relevant to the current use case. It includes the domain model objects such as Customer, Order etc. as well as objects such as services, factories and repositories.

The View is much simpler to define. It is simply a single representation of the Model. It is not uncommon for a system to have multiple views of the same model which present it in ways suitable for a specific context. The important thing to bear in mind here is that synchronisation of views in this type of system happens in the Model i.e. the Model is updated and then all views should reflect the change.

The common patterns are all based around these two concepts. What is different about them is how input is handled and how the components involved interact.

Model-View-Controller (MVC)

Model-View-Controller or MVC is the earliest of the main patterns. It was developed in the 70’s before modern presentation platforms existed and as such it doesn’t really make sense in many contexts today (for example when doing Windows programming).

As its name suggests it is made up of a View, a Model and a Controller which co-ordinates between the other two. The main features of MVC is that the Controller receives the user input directly. The importance of this becomes more apparent when you look at MVP. The basic workflow of MVC is that input is received by the Controller. The Controller then passes this input on to the relevant part of the Model which acts accordingly, often updating parts of the Model. The View then reflects these changes in the Model back to the user.

Generally the View and the Controller do not communicate directly. Instead the Model can be seen as the part of the system that connects them.

I often like to think of MVC in the context of the kind of apps that were originally written using it in which the user does not interact directly with the view but with some other piece of hardware. The hardware sends signals to the system which are dealt with by the Controller and the view is purely a one way view of the model. As we shall see with modern rich clients this pattern doesn’t make any sense any more, though when looking at the web world (and ignoring client side code) MVC is ideal.

Model-View-Presenter (MVP)

Modern rich client UI frameworks have the concept of Forms and Controls which not only display information to the user, but also accept input. Using this idea you can say that the View accepts the input instead of the controller. Because of this difference when compared to older presentation ideas the Model-View-Presenter (MVP) emerged.

Fundamentally the only difference between MVC and MVP is which component first receives the user input. The MVP pattern replaces the Controller with a new component called the Presenter (though generally the two names are interchangeable), but they both have pretty much the same role. However the View now receives the input and then sends a message to the Presenter which then carries on as the Controller would in MVC.

Modern MVP is split into flavours which differ in how the last part of the cycle is implemented i.e. how the View reflects the changes in the Model. Generally there are two main flavours known as Supervising Controller and Passive View, though in reality there are a lot of variants which often sits somewhere between the two.

Supervising Controller

Supervising Controller is effectively the original version of MVP and the closest to the original MVC pattern. Personally it is the style which is closest to how I prefer to implement it. In this pattern the View automatically reflects changes in the Model by taking advantage of the facilities of the presentation framework, which most often means using some sort of declarative binding. Where some more complex situation occurs the Presenter may manually update part of the View.

The idea with Supervising-Controller is that by removing the simple UI operations which can be done by the framework we reduce the responsibilities of the Presenter and focus on the complex parts of the presentation.

Passive View

Passive View on the other hand moves all UI logic into the Presenter, which now has both the responsibility of interacting with the Model appropriately for the received input and of updating the View to reflect those changes.

This approach mainly came about because people wanted to be able to increase testability and so making the View simple and dumb and putting the logic into the Presenter we can test that a faked out View is updated as we expect by the Presenter.

The Passive View pattern is good for simple scenarios when the view is fairly simple. It can become cumbersome when the amount of the View to be updated becomes large.

Another important thing to point out is that while Passive View came about to increase testability, that does not mean that Supervising Controller is not testable, the testability is largely down to the implementation chosen.

Hopefully I’ve done a decent job of explaining the basics of the various patterns. In reality the implementations of each varies based on the developer and the frameworks being used. Its is also true that there isn’t one single pattern that fits all situations. By understanding the core ideas of each however, we can better decide which model fits our needs

New year (nearly) new blog

noreply@blogger.com (Michael Wagg) — Mon, 22 Dec 2008 21:14:00 +0000

OK, so I haven't posted on my old blog for a bit of a long time. Moving to London kinda interrupted me and I can't think of any more excuses other than a combination of laziness and a really heavy workload.

Anyway since there is a new year coming it seems like a good time to get back into it. I thought I'd kick things off a little early by briefly mentioning the stuff I'll hopefully be blogging about.

Recently after doing quite a bit of work using the new ASP.Net MVC framework working, I have been working along with Tim Ross and Zubair Khan on a fairly complex WebForms project. Of particular interest was the UI layer which had a number of areas which were quite tricky in terms of how complex they became. This gave me a chance to use some of the ideas I picked up way back when doing WebForms development and between Tim, Zubair and myself I think we came up with some pretty good patterns for managing UI complexity.

None of it is particualry new of course but I'm suprised at how little is talked about beyond the basics of doing MVP with WebForms which is fine for many situations but often doesn't scale up when things get tricky.

Anyway hopefully I can get some of this posted so that firstly I can remember what I did and secondly so that it may be of use to others.