Before we jump into developing an application, we want to plan out what it will do. Imagine that you're working with a client that wants you to build them a website. Exactly what they ultimately want and need might not be immediately available, but a basic idea of what they definitely need from the system now is a start. You can sit down with a pen and paper with the client and kind of diagram everything, but for the purpose of this article we're going to present our diagrams in a digital format created with Gliffy.
Example: Social Networking Site
For our example, we'll imagine that we have a client that wants to build a social networking site, similar to Myspace or Facebook, with profiles for each user which include a photo and information about the user, and the ability to these profiles to associate with each other as contacts of some sort (kind of like how Facebook has 'friends').
We'll imagine that the client is wanting this application to be for some specific purpose, like a special community of people, but they haven't worked out all the details in their own mind. They just know so far that they want profiles for each user, with a photo, they want associations between users, and they also want the ability for users to send private messages to each other. The remaining details will come later.
Object Oriented Coding
Ruby is an object oriented language, which means that the resources that you create will have both properties/attributes, and will have certain actions that they perform. For instance you can think of a 'cat' as a type of object which always has two eyes, one nose, one mouth, and one tail (unless the cat has been abused). These are constants which would be hardcoded into what is known as a 'class'. A class is used to create an instance of each individual object, like the blueprint (or DNA) for each individual object. A class might define that each object also has certain properties which change (i.e. are variable), such as the color of the cats hair, or how much it weighs. Actions it might perform include 'meow' or 'walk' or perhaps even 'poop'.
This is a typical explanation of classes and objects in an object oriented language, but this example doesn't seem to suggest how object oriented coding applies to real life. Most of the time the actions which an object performs, formally known as 'methods', deal with the properties of the object itself. A real life example that applies with our example project is the 'user' class which would define that each user has a first and last name, stored separately in two properties of the object. There might be a method called 'full_name' which returns both the first and last name together, with a space between the first and last name.
If you've done object oriented programming, it may seem silly to input information into the computer and have it store the information in an object temporarily, and then that information is lost as soon as the program is done executing. The point of object oriented programming doesn't make sense when the state of the objects are lost. This is where databases become important. The state of a specific object, such as a 'user', can be loaded from a database record for that user, the user can be modified using the methods of the object which are defined by the class, and then the new state of the object can be saved to the database. This is how Ruby on Rails works. The classes you create for the resources you're working with are called 'models', and the properties of each object are stored in the database once you're done using the methods of that model to modify the resource in some way.
Here is a simple diagram for the first version of our project. It will have users which have a single photos. Users will have many contacts, and users will also have many messages sent to contacts.