non-random ramble

I just had a moment of clarity about refactoring and encapsulation. Its a simple truth and is one of the basic tenants of the concept and I had kind of forgotten about it.

It occured to me because I was working with some javascript. Its very easy to end up with lots of global methods in JS unless you use your closures properly.

By putting variables inside functions you can make them private.

Why is this useful. Well consider that you want to CHANGE one of those functions. Change ? who would EVER want to do that ?

If it is declared as a private function you KNOW FOR SURE that no-one else is using it and therefore that YOU CANNOT BREAK ANY OTHER CLASSES.

Therefore it is COMPLETELY SAFE TO REFACTOR.

great isnt it!

Such a thing you take for granted and yet when you work with a different language domain it suddenly reminds you of all the good things about OO.

There are 2 useful ones :

JSEclipse (http://www.interaktonline.com/products/eclipse/jseclipse/overview/)

and a CSS editor (http://csseditor.sourceforge.net/)

It wont have one if the directory you are in is already checked out!

This can happen if at some point you check out without specifying the full path.

eg:

svn co svnserver/myproject/trunk ~/myproject

rather than

svn co svnserver/myproject/trunk ~/myproject/trunk

We just had the privilege of hosting Eric Evans for half an hour at our project!

quick summary of what i scrawled down.

1) The MODEL : it was very clear to me that the model is neither a diagram, documentation or (which was the most interesting to me) the code. Quite often in agile we hear about the code being king! the code is the design, etc. Actually the model is an abstraction of all of these. THe code is the current expression of that abstraction and is therefore the only solid thing you have available. UML and documentation (he mentioned writing up key abstractions in the model such as Page – these could be made highly visible on walls or so) are TRANSIENT and provide a particular view of the model at any one time which can be useful for communication but is not necessarly the LAW.

2) Services : Should be orchestration rather than containing a lot of logic. The logic should be presented by the domain entities. Anything complex lives there, services should represent clearly defined abstractions of doing a particular thing. They can also represent an easy interface to the complexity of the domain.

To aid with design decisions about what should live in the service or the entity it helps to have a clear MODEL worked out and understood by everyone. The model will tell you where to put stuff, or it will feel more natural, it will guide you.

3) Model context boundaries: This is something interesting in the DDD book – models only have relevance within specific context and so it is important to define that context and anything that crosses the boundary must be translated into the other context.

4) Crossing boundaries or interacting with other domain models. There are 2 strategies, Conformist or Anti-corruption layer Conformist means to take the same object model. Anti-corruption layer means to build an adapter between the two contexts.

5) We have 2 clients of our Domain objects, people who edit content and the people who design the front end pages using velocit and CSS. We asked the question as to wether there should be additional translation into the front end “model”. Perhaps there are 2 domain contexts’ here? The thought was that for our system it might be better to keep the core model as a set of concepts and just exntend those concepts to provide a more useful interactio with the presentation layer. One of the problems is classes getting really big, so maybe splitting them up into smaller, functionally cohesive units which are more suitable for different applications.

By the same token we should be extracting the CONCEPTS from the front end and building them into the model. This totally highlights the idea that the model is a conceptual abstraction of the software, not a particular artifcat such as the code or a diagram.

We have been more focused on the content building side and have done good work modelling the domain from that aspect, potentially we need to move that modelling into the front end.

6) MODELLING is different to Software DESIGN : this is not something he said but something i think might be implied by the modelling stuff.

If the MODEL is not the CODE, it cannot be the design of the software. Therefore, MODELLING as an activity is a more abstract than writing the code – the DESIGN of th ecode should fall out if the model is well defined and understood. The MODEL is more about principals and ENTITIES than low leve code design.

What a great afternoon!

Just had a really interesting discussion about design and over-design.

I was asking someone their opinion about using raw collection types instead of introducing a specific domain object. The type in question was a map of integers to lists of strings.

We chatted for a while about it and came to no firm conclusion, had some good principals though, like code readability and ease of maintennance.

After we realised that I was just about to come up against a bit of code which makes the decision for me – I suddenly required extra information about this map, which I would have to pass in another map, or introduce a domain object.

Suddenly its not an esoteric design argument but a concrete necessity.

This is something ive noticed before but not formalised… If you cant make a decision about something, don’t do it just make sure its not duplicated, etc all the basics.

As soon as a decision becomes esoteric or starts being about what things might get used for, YAGNI kicks in.

This could be summed up as Delay design decisions until as late as possible wait for a compelling reason to do something and then refactor rather than spend hours arguing over a beautiful design which will always be wrong.

This fits well with kent becks idea that you are always adding features to an existing system. Change the system just enough to make it simple for you to add the feature then move on.