Applying OO principles to interpersonal relationships

I formally admit my geekiness by seeing the interesting similarities between good OO design and healthy interpersonal relationships.

Healthy boundaries
Objects need to collaborate and interact and depend on each other, but it's important to maintain healthy boundaries.  Other objects are not allowed to touch your private parts, and you get to say what is visible and what is not.

Multitasking

Objects must know how to handle multiple requests at once while maintaining their state.  


Grace Under Pressure
Well-designed objects need to be able to handle stress and overload.

Honoring your commitments

Objects provide public interfaces, which provide an agreement as to what they are willing to do.  You can not change your agreements without talking about it first.

Interdependence

No object is an island unto itself; all objects have dependencies on other objects.  But an object should not be overly dependent on others, as this means it becomes fragile to changes made in the other object.

However, it's important to recognize there are some OO principles that should not be applied to relationships.

Single Responsibility Principle - each object has one and only one responsibility in a system.  Shyeah, right.

Pluggability - you should be able to replace one object with another that plays the same role.  No thanks.

TDD taken to logical conclusion - write acceptance tests first

I'm reading an interesting book called Growing Object-Oriented Software Systems by Steve Freeman and Nat Price (based on @mfeathers recommendation).

For the most part the first two chapters are nothing new for me (I'm expecting that will change in subsequent chapters), but there was one thing that made me stop and step back.  To me TDD has been about unit tests, but they strongly recommend something that I had never though of before but which made a lot of sense.  Not only do you write tests first at the unit level, you also write your end-to-end acceptance test first.

This gave me pause.  I am so used to QA reactively writing acceptance tests either after or in parallel with feature development.  But the more I thought of it, the more it made sense.  It defines a contract in black-and-white, and it also helps you focus on building just as much as you need and no more.

Of course the acceptance tests will break, and then you work towards making it pass by writing unit tests that break and making those unit tests work.  This really makes sense, and I'm going to try this with my next project.  I talked with our QA engineer, and he loves the idea and wants to give it a go.

If it works, I'll talk to the rest of the team about it.  This is the kind of thing that turns standard development process on its head and has to be introduced very gently... :)