Object-Based Design
(Solving Problems with Objects in Mind)

The First Design Step:

The first step in determining how to solve a problem is to truly understand what is required.  Although we can think about the pieces required for the problem in a relatively random order, it is important to keep the overall goals in mind.

In particular, one needs to know the possible inputs that can exist and what possible outcomes are wanted in each scenario. In software engineering, the term for fully understanding the problems is called requirements analysis. This does not preclude you from thinking about how to solve the problem during this phase (although there are potential drawbacks in attempting to "pre-solve" the problem).

Once you understand the problem, youcan ask yourself "what will be the important parts of the problem?" In particular,

Some of the elements and actions can be determined just from knowing that certain pieces are going to be necessary to solve the problem.

As a rule of thumb, any noun (or "thing") that arises when looking at a problem is potentially an element.  Similarly, any verb is potentially an action.

Getting a list of elements and actions is the first step of designing a model for a solution to the  problem.  In Java, elements correspond to objects (defined by a class) and actions correspond to methods provided by some class.

The Second Design Step:

Part 1 (deciding on object types):

Not every noun needs to be an object.  For example, although a social security number is a noun, it is usually associated with a person (another noun).  A person generally is a reasonable object, but a social security number (in such a context) is not so much an object in its own right. It is better described as an attribute of the person object. Noun-like attributes of objects correspond to the state of an object (the values of the instance variables of the object's defining class).  Continuing the example, each person is a distinct object and the state of that person included the values of its attributes (e.g., social security number and  name).
Part 2 (organizing actions):
It's also useful to determine which actions only involve a single object and which actions involve multiple objects. Actions that only involve a single object are basic methods (not much different than attributes) that may be accessors or mutators of an object.

Actions that involve multiple objects of the same class are somewhat more involved. Actions that involve multiple objects of different classes are interactions and will be the most difficult to design correctly.

In 15-100, we won't  be dealing with complex  interactions between classes. I'm a firm believer in UML (the Unified Modeling Language) which is addressed in our text. The advantages of UML are noticable when dealing with these more complicated actions. Appreciating UML will be useful to students who wish to take further CS courses. Understanding UML will be necessary for those of you who end up in important programming jobs.


Once the design is determined,  the advantage (to solving a large problem in this way) is that the problem has been divided into simpler (solvable) problems. Because we have deconstructed the original problem into appropriate pieces (objects and methods (both actions and interactions)), an individual programmer can focus on solving these much simpler problems -- namely, coding the objects and methods.

Coding Your Design:

You cannot "code" an object.  Instead, you write code for a class which describes all objects of that type. Basically, the description of a person, for example, is a class. This is a more abstract concept than an actual person (an object).

A class describes the state (what kind of data is important for the object) -- for example, a simple part of a person is their age (an integer).
An actual person is more closely associated with the class data (e.g., age 19) -- a particular person is an object of the class that defines "that" person. The state of a person object is also associated with that "data".  Although it makes sense to think of the age component for a person object as 19,  it doesn't make sense to associate a particular value with the description.  I'll often  refer to an object as an instance of a class; in other words, objects are class instances.  Within a class, the instance variables  store the state of a class instance .

When you consider actions and interactions, things are a little more grey. However, since you're just starting out, actions won't be complicated and you can currently associate every action with a method.  A method is an action associated with an object.  The set of all methods of an object is called its behavior.

Every object of a class possess the same behavior. The code for a method describes how the action is supposed to occur.

Most interactions between multiple objects of the same class can be represented through object or class methods (although the code will seem more complicated at first).

How you code an interaction between objects of different classes is dependent on the object-oriented language that you're using.  In Java, such interactions sometimes can be coded as basic methods but generally inheritance or interfaces will be required to provide a general solution. These will be topics that will be introduced later in the course.