Object Discovery

This post is a write-up of a user group session at DareDevs on 20th November 2013, delivered by Kevin Rutherford

Start with a "semantic model". This is a loose list of nouns in the business domain along with the loose relationships between them.
We're never taught about "thinking" in objects. The reason many TDD tutorials that start with the first test are so good is that we're not shown the 30 seconds of design in the author's head that identifies the objects that need to be tested.
Kevin says, "If nothing else, understand that the primary reason your code is poor is because state changes in our objects are not broadcast. This is the reason we have getters on our object properties. State changes must be asked for by other objects rather than the object whose state has changed."
The real "meat" of any Object-Oriented system is not the objects themselves, but the messages that pass between them.
Use Object Cube diagrams and CRC Cards to design and map your objects.

Two key take-aways
- Focus on events raised. This decouples objects from each other.
- Stop taking a "god-like" view of all objects together. Examine only each single object at a time and focus on it's responsibilities.