The Links That Bind

My daughter is usually driven to and from school during the week by her nanny. For this reason, the child seat usually stays in the nanny's car until the weekend.

This has been fine up until recently, when the nanny's car started going through a rough patch mechanically. Twice, in the last fortnight, I have received a call that the car has broken down, or won't start. Apart from the inconvenience of taking 'little Missy' to school ourselves before going to work, we have had to retrieve the means of getting her to school: ie the child seat! This, at a time when an already overloaded traffic system was thrown into chaos by the domain tunnel closure, made for even more time lost.

We've actually been pretty lucky wrt absences. If the nanny has called in sick, it's usually been at the start or end of the week, and we have had the seat. Not this time!

The simple interim solution has been to agree that the seat is to be left at our house in the evenings.

So, you might be wondering what this little domestic drama has to do with bad programming? Simply to point out that, while it might be convenient to have underlying links between class objects that have a lot to do with each other, greater flexibility is achieved when you define the links explicitly with each transaction.

Just as we now put in the child seat each morning and take it out again in the evening, always think about passing a reference to another class as a parameter and don't expect it to be stored, or picked it up from somewhere. The onus on providing the necessary information for an object^* to do its job should rest with the client program. That way, your objects can exist a little more independently of each other.

And so can you!

^*For the record, I do not consider my daughter's nanny as an object!