Chapter 3 Object Think Chapter 3 Objectives l

Chapter 3 “Object Think”

Chapter 3 Objectives l Introduction l The need to change your thinking l Techniques for changing your thinking l “Object Think” for familiar objects l “Object Think” for problem domain objects

Introduction l Objects in a computer systems l can be programmed with attributes l can be programmed with procedures l Need testing so that objects are reliable l correct attributes l correct procedures

The need to change your thinking l Developers cannot specify every procedural detail in a complex computer system. l reusable objects can take care of the details Most developers have thought for a long time that computer systems are collections of programs. l As an application evolved, developers built a generalization / specialization hierarchy. l

The need to change your thinking l Hierarchy l computer system is a collection of programs l program is a collection of code modules l code module is a collection of procedures l a procedure is a set of very detailed instructions l Under that paradigm, systems development means programs and programming

Changing your Thinking l New approach follows two techniques CRC 2. Object Think (Coad and Nicola, 1993) 1. l CRC class l responsibilities of that class l collaborators (Beck and Cunningham, 1989) l

CRC Cards l l l Group of people get together to learn about OO Index cards are used to represent the classes or types of objects in a system. Each person gets a card and then pretends to be one of the objects in a system and acts the way their object is supposed to act. People in the group discuss their responsibilities, as objects. They become used to talking about objects in terms of their attributes, procedures, and collaborations. Eventually the group acts out the interactions that are necessary to carry out these responsibilities.

Object Think Tries to get us to think of proven objects in a computer system as being trustworthy. l One way to do this is to let the object talk about itself. l Trustworth objects can take care of details. l ie: a button that appears on a window of a GUI. l l A button on the screen Knows what window it is attached to. l Knows its position in the window. l Knows its height and width. l Knows its background color. l Knows what the label that appears on it says. l Knows what to do when clicked. l

What a window and a button know

Object Think We can carry the “object think” approach and imagine an end user carrying a conversation with a word processor document: l OK word-processing document: l l l Set your left and right margins to 1 inch. Add page numbers centered at the bottom of your page Keep the usual settings for everything else Center these words at the top of page 1: My ideas for the day Add a new paragraph, left justified l l Ideas for today are as follows. . Now indent all of the following items, each as an item in a list. . Answer my e-mails l Check stock prices. . Etc. l l OK, check spelling

User interaction with a document object

“Object Think” For Problem Domain Objects l Consider an object called “dog” l could think about “dog” as an object that knows things and knows how to do things Depends on context l If you think about the dog object from a veterinarian’s perspective that would be quite different. l Dog object is not a actual dog l only an object in an information system l put there because dogs are part of the problem domain l

“Object Think” for Problem Domain Objects l Veterinarian needs to remember certain things about all dogs. l l OO view of domain creates system that contains a class of objects called dog. l l needs an information system that stores this information and that can operate on it dog is an abstraction of real world dogs tailored to the needs of the vet What does the veterinarian want each dog object to do? l each dog object should know how to do things required within the veterinarian domain

“Object Think” for Problem Domain Objects l A problem dog object doesn’t know how to bill itself l billing is very important to the veterinarian l Using object think approach, dog object has been asked to do something it does not know how to do. l In this case, the veterinarian object needs to access the dog-owner object l veterinarian object sends bill to dog-owner object l dog-owner object is responsible for paying the bill that applies to dog object l

“Object Think” For Problem Domain Objects l l l Problem domain objects are similar to data entities identified when an analyst models data. Most information system developers are fairly comfortable with problem domain data entities. Procedures can be added to data entities. The result is a class. An instance of a class is a specific object. a specific dog l a specific owner l Objects are independent of each other. l Objects can communicate with each other. l

Review Questions Why is the OO approach sometimes difficult for experienced system developer? 2. What are two techniques for changing people’s thinking about objects? 3. What capabilities can you assume objects have? 4. What are the dangers of placing too much trust in reusable objects? 1.