[...] Previously, I described a general approach to solving Nonograms. I didn’t go into many details about the actual implementation. Here I go further, in an effort to win back some of the sunk cost involved in the development. [...]

I give more details about the software and address Alastair’s questions in the next section of this series of posts about Nonograms.

Nice work. http://sourceforge.net/projects/nonogramsolver is free.

Some observations:

Firstly it seems that object-oriented analysis is the real winner here. I’m sure it would be possible to code this in a strictly procedural (or even functional?) programming language but I wouldn’t want to try it. I think the key benefit here of OO is to separate the task of modelling the rules of the puzzle from the task of solving it. Just curious whether you enforced this separation in the code itself?

Secondly with regard to the domain modelling, I’m interested why you chose the white segment maximum length to be the grid size, when it plainly could never get to this size? Does it affect your analysis if you put a more realistic upper limit on the white segment sizes (eg grid size minus coloured segment sizes at least)? I suspect it doesn’t but it stuck out as an anomaly to me.

Perhaps you can tolerate some inaccuracy in the domain modelling (eg in the maximum length of the white segments), on the assumption that you’re not going to require it at puzzle solving time. This breaks the modelling/solving separation mentioned above, but it’s the 80/20 rule, and that should be the software engineering mantra. Another way of looking at it is just-in-time modelling – adding accuracy to the model as you know you need it and not before. The trick of course is knowing when you need it.