CSC/ECE 517 Fall 2009/wiki3 10 ot
Introduction
This article discusses “Object Think” brainstorming methodology. It is intended for experienced programmers who write their code in Object oriented style. This article should be viewed as a guideline and not as a set of rules that must be enforced. In this article the word “entity” means a real-life entity, i.e. chair, apple, bird, shopping cart etc. The word “object” means a model that is used to describe a real-life entity.
Here is what [1] says about object think and object oriented development:
Poor object thinkers put data and functions into objects haphazardly. At best, they use a set of guidelines they find difficult to explain. This makes their models and code difficult to understand and brittle to changes in requirements and system growth. When requirements change, a brittle object model must significantly alter its structure by redefining objects. Object models built through functional analysis are filled with objects representing functions which makes them notoriously brittle as changes in functional requirements render objects obsolete, and reorder collaborations among them.
Good object thinkers apply consistent principles for distributing data and functions; they can explain and justify the results in their object models by relating them back to the objects in the business domain. Object models built with object think remain stable as the requirements and the system evolve because the model mirrors real-world objects and their relationships. New requirements mean more of the domain is being modeled or more responsibilities are being given to the objects that are already modeled. These changes are neatly encapsulated in a stable object model by adding new objects and expanding objects’ responsibilities. Objects do not change their meaning or lose collaborators, so the underlying structure of the model remains intact even as layers are snapped on top of it.
What is “Object Think”?
“Object Think” is a brainstorming methodology for architecting software. This methodology encourages a developer to think just like real-life entities. An object will abstract the entity’s responsibilities, collaborations, and even it’s “persona”. In other words the developer is encouraged to “think” like an entity, “behave” like an entity and even “talk” like an entity. It is a good idea to adopt a first-person voice during development of a model of an entity by an object. I.e. I’m an object. What do I know about myself? What do I know about the world around me? What can I do with myself? What can I with others? What is my function? e.t.c.
Here are a set of principles that were outlined by [1] when developing with object think:
- Personify Objects. Object model a domain by imagining its entities as active, knowing objects, capable of performing complex actions.
- Give Object Responsibilities. Turn information about a real-world entity and the actions performed on it into responsibilities of the object representing the entity.
- Object’s responsibilities. An object’s responsibilities are: whom I know – my collaborations with others; what I do – my services; and what I know – my properties
- Talk Like an Object. To scope an object’s responsibilities, imagine yourself as the object, and adopt the first-person voice when discussing it.
Let’s consider several examples which will help us better understand what object think is and how it works
Examples
A shopping cart in the e-commerce application
I’m a shopping cart. I know how many products are in me. I know the total price of the products in me. I can empty myself by throwing everything away from me or by going through a checkout. I know that I’m used by a user.
From this we can see that this object most likely will contain a set of product objects, total_price property, an empty method which can be used in two ways, either by going through a checkout or by the user who can empty it out.
A tire in the tire manufacturing plant
I’m a tire. I know my manufacturer. I know that if I haven’t passed the testing stage I will be recycled, and I did pass a testing stage I will be used. I know what components I’m made of and their quantity. I know the exact process of how I’m made. I know brands and models of cars I should be used with. I know the date of my manufacturing and the date I was put on a wheel of a car. I know the mileage I should be used for. I know my warranty. I also know how I should be recycled.
From this example certain methods can be clearly seen: manufacture, recycle, a method to return if the testing was passed, return the date of manufacturing, and the date a tire was placed on a wheel, return models and brands of cars that this tire is compatible. It also can be seen that a tire will contain other objects inside of it, such as components it is made of.
A peanut butter jelly sandwich in the kitchen
This example was taken from [1], [2]
I’m a peanut butter jelly sandwich. I’m always made with two slices of the same type of bread. I know that a thin bread slice cannot support chunky peanut butter (assumption) and a thin bread slice cannot support a heavy application of ingredient. I know that one bread slice must contain peanut butter and the other must contain jelly.
This example is a bit harder than previous two. Here are the requirements that we can derive from this description:
- a sandwich requires two slices of the same type of bread
- a thin bread slice cannot support chunky peanut butter
- a thin bread slice cannot support a heavy application of an ingredient
- one bread slice must contain peanut butter and the other must contain jelly.
Now consider the peanut-butter-and-jelly sandwich business process. Creating the application transaction is the crucial step in the business process of building a peanut-butter-and-jelly sandwich because this step verifies the business rules as it tries to link the application object to its ingredient and bread slice collaborators. So, which object makes the application transaction? Is it (a) the sandwich, (b) the slice, (c) the ingredient, or (d) the ingredient manager-controller?
Clearly, the choice is between the bread slice and the ingredient; they are the collaborators of the application, and they have the relevant information and business rules. Use first-person object think to pick between the two. For the bread slice, object think says, "I am a bread slice. I have an ingredient applied on me in either a light or heavy amount." For the ingredient, object think says, "I am an ingredient. I apply myself to a bread slice in either a light or heavy amount." Notice that the action of applying ingredient is third-person for a bread slice and first-person for an ingredient. Obviously, the correct answer is (c); an ingredient creates the application object when it applies itself on a bread slice.
Figure for a complete Peanut-Butter Sandwich object model. [1], [2]
References
[1] Streamlined Object Modeling, Jill Nicola, Mark Mayfield, Mike Abney
[2] http://www.informit.com/articles/article.aspx?p=25184&seqNum=3