Ruby, the programming language underlying Ruby on Rails, is an Object Orientated Programming (OOP) language. OOP's use of objects to store and manipulate data can point to a useful approach to use when deciding how to group data. That is, to consider the real world entities you are modeling with your application and then mapping the data objects to those entities. Groups of data are then defined as objects.
Let us use this approach to address Rory's problem on how far to separate his data down into object groups, by considering how the data relates to the real business entities he is trying to model.
- People—the core real entities within the contact data are the people the list is being used to track.
- Companies—in simplistic terms, these are the business groups people in the contact list belong to.
- Addresses—the labels that allow us to identify the geographical location of the premises where companies and people reside, and that we can send information and materials via the postal system.
- Email addresses—the labels used to identify and locate people within the Internet space and to which we can send messages and data to via email.
- Telephone numbers—the labels used to identify the telephone a person uses and its location within the telephone network.
- Dates—Key dates tracked so as to allow the sales team to develop their relationship with current and potential customers.
So, how do we use this breakdown of data objects to decide how the data should be split? The best approach is to create a simple set of rules and then use those rules to test each data object to see if it passes or fails. The rules need to describe the features of a data object that makes it worthwhile separating them from the rest of the data and treating them separately.
Rory looks at his data, considers what he is trying to achieve by separating the data into objects, and comes up with the following rules:
- A data object must comprise more than one piece of data. There is little point in separating out the data if all you achieve is to add a pointer to a unique piece of data.
- The data within an object must relate directly to the entity described by the object. Data has to be grouped logically or you may as well just group it by the position within the list or not group it at all.
- Separating the data object must provide a benefit that is not available or as easily achieved if the data is not separated.
Using these rules, Rory is able to remove email addresses, telephone numbers, and dates as candidates for separating into objects. Each of these items is a self-contained single entity within Rory's data, and therefore, fails both rule 1 and 3. With each of these, it is easiest to store them as single fields within the data and no obvious benefit is apparent from separating them out. They will need individual methods to handle them and carry out processes such as validation, but that is easy to handle at the field level.
This leaves people, companies, and addresses.