CHAPTER1

The Object-Oriented Paradigm

Dr. Murad Al-Rajab
Overview
• This chapter introduces you to the object-oriented paradigm by
comparing and contrasting it with something familiar: standard
structured programming.

2
The object-oriented paradigm
• The object-oriented paradigm grew out of a need to meet the
challenges of past practices using standard structured programming.
• By being clear about these challenges, we can better see the
advantages of object-oriented programming, as well as gain a better
understanding of this mechanism.

3
In this chapter,
• We discuss a common method of analysis, called functional
decomposition.
• We address the problem of requirements and the need to deal with
change (the scourge of programming!).
• We describe the object-oriented paradigm and show its use in action.
• We point out special object methods.
• We provide a table of important object terminology used in this
chapter

4
Design Methods
• Ways of solving problems

• Structured Design/Programming (a.k.a. functional decomposition)

• “Think in terms of steps”

• Functional Programming (a.k.a. declarative programming)

• “Think in terms of functions and their composition”

• Object-Oriented Design/Programming

• “Think in terms of objects that do things”

5
Before The Object-Oriented Paradigm:
Functional Decomposition
• If you were given the task of writing code to access a description of
shapes that were stored in a database and then display them, it
would be natural to think in terms of the steps required. For example,
you might think that you would solve the problem by doing the
following:
1. Locate the list of shapes in the database.
2. Open up the list of shapes.
3. Sort the list according to some rules.
4. Display the individual shapes on the monitor.

6
Functional decomposition is a natural way to
deal with complexity
• You could take any one of the previous steps and further break down
the steps required to implement it. For example, you could break down
Step 4 as follows:
• For each shape in the list, do the following:
4a. Identify type of shape.
4b. Get location of shape.
4c. Call appropriate function that will display shape, giving it the shape’s location.

This is called functional decomposition because the analyst breaks

down (decomposes) the problem into the functional steps that
compose it.
7
Functional decomposition is a natural way to
deal with complexity (Cont.)
• The problem with functional decomposition is that it does not help us prepare
the code for possible changes in the future, for a graceful evolution. When
change is required, it is often because I want to add a new variation to an existing
theme.
• For example, I might have to deal with new shapes or new ways to display
shapes.
• If I have put all of the logic that implements the steps into one large function or
module, then virtually any change to the steps will require changes to that
function or module.
And change creates opportunities for mistakes and unintended consequences.
Or, as I like to say,
Many bugs originate with changes to code.
8
The challenge with this approach:
dealing with change
• And no matter how hard you try, no matter how well you do your
analysis, you can never get all of the requirements from the user.
• Too much is unknown about the future. Things change. They always
do . . .

9
The Problem of Requirements
• Ask software developers what they know to be true about the
requirements they get from users. They will often say:
• Requirements are incomplete.
• Requirements are usually wrong.
• Requirements (and users) are misleading.
• Requirements do not tell the whole story.

• One thing you will never hear is, “not only were our requirements
complete, clear, and understandable, but they placed out all of the
functionality we were going to need for the next five years!”
Requirements always change. 10
Dealing with Changes:
Using Functional Decomposition
• Look a little closer at the problem of displaying shapes. How can we
write the code so that it is easier to handle shifting requirements?
• Rather than writing one large function, I could make it more modular.
• For example, in Step 4c on slide 6, where we “Call appropriate
function that will display shape, giving it the shape’s location,” we
could write a module like that shown in Example 1-1.

11
Example 1-1 Using Modularity to Contain
Variation

Then, when we receive a requirement to be able to display a new

type of shape—a triangle, for instance—we only need to change
this module (hopefully!).

12
Problems with modularity in a functional
decomposition approach
• There are some problems with this approach, however. For example,
we said that the inputs to the module were the type of shape and a
description of the shape. Depending upon how we are storing shapes,
it may or may not be possible to have a consistent description of
shapes that will work well for all shapes. What if the description of
the shape is sometimes stored as an array of points? Would that still
work?
• Modularity definitely helps to make the code more understandable,
and understandability makes the code easier to maintain. But
modularity does not always help code deal with all of the variation it
might encounter.

13
Low cohesion, tight coupling
• With the approach that we have used so far, we find that we have two significant
problems, which go by the terms low cohesion and tight coupling.
• In his book Code Complete, Steve McConnell gives an excellent description of
both cohesion and coupling. He says,
Cohesion refers to how “closely the operations in a routine are related.”
• We have heard other people refer to cohesion as clarity because the more that
operations are related in a routine (or a class), the easier it is to understand
things.
• Coupling refers to “the strength of a connection between two routines”. Coupling
is a complement to cohesion. Cohesion describes how strongly the internal
contents of a routine are related to each other. Coupling describes how strongly a
routine is related to other routines. The goal is to create routines with internal
integrity (strong cohesion) and small, direct, visible, and flexible relations to other
routines (loose coupling).

14
Changing a function, or even data used by
a function, can cause disaster on other functions
• Most programmers have had the experience of making a change to a
function or piece of data in one area of the code that then has an
unexpected impact on other pieces of code.
• This type of bug is called an “unwanted side effect.” That is because
while we get the impact we want (the change), we also get other
impacts we don’t want—bugs! What is worse, these bugs are often
difficult to find because we usually don’t notice the relationship that
caused the side effects in the first place (if we had, we wouldn’t have
changed it the way we did).
We really do not spend much time fixing bugs.
15
Functional decomposition focuses on the
wrong thing
• With functional decomposition, changing requirements causes our
software development and maintenance efforts to thrash.
• We are focused primarily on the functions. Changes to one set of
functions or data impact other sets of functions and other sets of
data, which in turn impact other functions that must be changed.

16
Dealing with Changing Requirements
• How do people do things?
• Will you follow a structured programming approach?
• What is the impact of this?

17
Transitioning to the OO Paradigm
• To figure out a way around the problem of changing requirements and to see if there is
an alternative to functional decomposition, let’s look at how people do things.

• Let’s say that you were an instructor at a conference. People in your class had another
class to attend following yours, but didn’t know where it was located. One of your
responsibilities is to make sure everyone knows how to get to their next class.
• If you were to follow a structured programming approach, you might do the following:
1. Get list of people in the class.
2. For each person on this list:
a. Find the next class they are taking.
b. Find the location of that class.
c. Find the way to get from your classroom to the person’s next class.
d. Tell the person how to get to their next class.

18
Transitioning to the OO Paradigm (Cont.)
• With functional decomposition, you would develop a program to solve this problem that would
have you the instructor do everything

• get the roster, loop through each attendee, look up their next session, find its location,
generate a route, and, finally, tell the attendee how to get to their next class
• To do this would require the following procedures:
1. A way of getting the list of people in the class
2. A way of getting the schedule for each person in the class
3. A program that gives someone directions from your classroom to any other classroom
4. A control program that works for each person in the class and does the required steps for each
person

• You would do everything, attendees would do (almost) nothing

19
How do people do things? (Cont.)
• I doubt that you would actually follow this approach. Instead, you would probably post
directions to go from this classroom to the other classrooms and then tell everyone in
the class, “I have posted the locations of the classes following this in the back of the
room, as well as the locations of the other classrooms. Please use them to go to your
next classroom.”
• You would assume that everyone has a conference program, knows where they
need to be next, and will get their on their own

• All you would do is end the session and head off to your next activity

• At worst, you would have a list of the next sessions at the front of the class and
you would tell everyone “use this info to locate your next session”

20
Compare / Contrast
• In the first scenario,

• you know everything, you are responsible for everything, if something changes you would be
responsible for handling it

• you give very explicit instructions to each entity in the system

• In the second scenario,

• you expect the other entities to be self sufficient

• you give very general instructions and

• you expect the other entities to know how to apply those general instructions to their
specific situation

21
Benefits of the second scenario
• The biggest benefit is that entities of the system have their own responsibilities

• indeed this approach represents a shift of responsibility away from a central control
program to the entities themselves

• Suppose we had attendees and student volunteers in our session and that volunteers needed to
do something special in between sessions

• First approach: the session leader needs to know about the special case and remember to tell
volunteers to do it before going to the next session

• Second approach: the session leader tells each person “Go to your next session”; volunteers
will then automatically handle the special case without the session leader needing to know
anything about it

• We can add new types of attendees without impacting the leader

22
Revisiting the Shape system
• Recall our “display shapes” program from earlier in the lecture

• How would you rearrange it to follow this new approach?

23
Foreshadowing
• The benefits we’ve been discussing are natural in the OO approach to analysis, design and
implementation that we will be learning this entire semester

• self-sufficient entities ➡ objects

• “give general instructions to” ➡ code to an interface

• “expect entities to apply those general instructions to their specific situation” ➡

polymorphism and subclasses

• “add new attendees without impacting session leader” ➡ code to an interface,

polymorphism, subclasses

• shift of responsibility ➡ functionality distributed across network of objects

24
As an aside...
• OO main programs tend to be short

• On the order of create an object and send a message to it

25
The Object-Oriented Paradigm
• The object-oriented paradigm is centered on the concept of the object.
• Everything is focused on objects.
• It produces systems that are networks of objects collaborating to fulfill the
responsibilities (requirements) of the system
• Objects are conceptual units that combine both data and behavior
• We write code organized around objects, not functions.
• The data of an object is referred to by many names
• attributes, properties, instance variables, etc.
• The behavior of an object is defined by its set of methods

• Objects inherently know what type they are. Its attributes allows it to keep track of
its state. Its methods allow it to function properly.

26
What is an object?
• The advantage of using objects is that we can define things that are
responsible for themselves. (See Table 1-2.)

27
What is an object? (Cont.)
• The objects were identified by looking at the entities in the problem
domain.
• We identified the responsibilities (or methods) for each object by
looking at what these entities need to do. This is consistent with the
technique of finding objects by looking for the nouns in the
requirements and finding methods by looking for verbs.
• We find this technique to be quite limiting and will show a better way
throughout the course.
• For now, it is a way to get us started.

28
How to think about objects
• The best way to think about what an object is, is to think of it as something with responsibilities.

• As you perform analysis (What’s the problem?), you discover

responsibilities that the system must fulfill

• You will eventually find “homes” for these responsibilities in the

objects you design for the system; indeed this process can help
you “discover” objects needed for the system

• A good design rule is that objects should be responsible for themselves and should have those
responsibilities clearly defined.

29
Objects
• Conceptual — a set of responsibilities

• Specification — a set of methods

• Implementation — a set of code and data

• Unfortunately, OOD is often taught only at the implementation level

• if previously you have used OO programming languages without doing analysis and design up
front, then you’ve been operating only at the implementation level

• as you will see, there are great benefits from starting with the other levels first

30
Objects as Instances of a Class
• If you have two Student objects, they each have their own data

• e.g. Student A has a different set of values for its attributes than Student B

• But they both have the same set of methods

• This is true because methods are associated with a class that acts as a blueprint for
creating new objects

• We say “Objects are instances of a class”

• Classes define the complete behavior of their associated objects

• what data elements and methods they have and how these features are accessed (whether
they are public or private)

31
Objects have interfaces for other objects to
use
• Since objects have responsibilities and objects are responsible for
themselves, there has to be a way to tell objects what to do.
• Remember that objects have data to tell the object about itself and
methods to implement functionality.
• Many methods of an object will be identified as callable by other
objects. The collection of these methods is called the object’s public
interface.

32
Example
• For example, in the classroom example, we could write the Student
object with the method gotoNextClassroom(). We would not
need to pass any parameters in because each student would be
responsible for itself. That is, it would know:
• What it needs to be able to move
• How to get any additional information it needs to perform this task

33
Organizing objects around the class
• In object-oriented terms, the general student is called a class.
• A class is a definition of the behavior of an object.
• It contains a complete description of:
• The data elements the object contains
• The methods the object can do
• The way these data elements and methods can be accessed
• Since the data elements an object contains can vary, each object of
the same type may have different data but will have the same
functionality (as defined in the methods).

34
Objects are instances of classes
• To get an object, we tell the program that we want a new object of
this type (that is, the class that the object belongs to).
• This new object is called an instance of the class.
• Creating instances of a class is called instantiation.

35
Classes (I)
• The most important thing about a class is that it defines a type with a legal set of values

• Consider these four types

• Complex Numbers ➡Real Numbers ➡Integers ➡Natural Numbers

• Complex numbers is a class that includes all numbers; real numbers are a subtype of complex
numbers and integers are a subtype of reals, etc.

• in each case, moving to a subtype reduces the set of legal values

• The same thing is true for classes; A class defines a type and subclasses can be defined that
excludes some of the values from the superclass

36
Classes (II)
• Classes can exhibit inheritance relationships

• Behaviors and data associated with a superclass are passed down to instances of a
subclass

• The subclass can add new behaviors and new data that are specific to it; it can also alter
behaviors that are inherited from the superclass to take into account its own specific
situation

• It is extremely desirable that any property that is true of a superclass is true of a subclass;
the reverse is not true: it is okay for properties that are true of a subclass not to be true of values
in the superclass

• For instance, the property isPositive() is true for all natural numbers but is certainly not true of
all integers

37
Working with objects in the Instructor
Example
• Writing the “Go to the next classroom” example using an object-
oriented approach is much simpler.
• The program would look like this:
1. Start the control program.
2. Instantiate the collection of students in the classroom.
3. Tell the collection to have the students go to their next class.
4. The collection tells each student to go to their next class.
5. Each student:
a. Finds where his next class is
b. Determines how to get there
c. Goes there
6. Done.

38
The need for an abstract type
• This works fine until I need to add another student type, such as the
graduate student.
• The solution is straightforward. We need a general type that
encompasses more than one specific type. In this case, we want a
Student type that includes both RegularStudents and
GraduateStudents.
• In object-oriented terms, we call Student an abstract class.

39
Abstract classes define what a set of classes
can do
• Abstract classes define what other, related, classes can do.
• These “other” classes are classes that represent a particular type of
related behavior.
• Such a class is often called a concrete class because it represents a
specific, or nonchanging, implementation of a concept.
• In the example, the abstract class is Student. There are two types of
Students represented by the concrete classes,
RegularStudents and GraduateStudents.
RegularStudent is one kind of Student and
GraduateStudent is also a kind of Student.
40
Abstract classes define what a set of classes
can do (Cont.)
• This type of relationship is called an is-a relationship, which is
formally called inheritance. Thus, the RegularStudent class
inherits from Student.
• Other ways to say this would be, the GraduateStudent derives
from, specializes, or is a subclass of Student.
• Going the other way, “the Student class is the base class,
generalizes, or is the superclass of GraduateStudent and of
RegularStudent.

41
Abstract Classes
• The classes that sit at the top of an object hierarchy are typically abstract classes while the
classes that sit near the bottom of the hierarchy are called concrete classes
• Abstract classes
• define a set of generic behaviors for a related set of subclasses;

• act as placeholders for other classes defining method signatures that they must implement,
defining method bodies for behaviors that should be the same across all subclasses, defining
data that will be useful for all subclasses

• We use them to define the methods their derived classes must implement.
• In OO programming languages, abstract classes cannot be instantiated

• instead you instantiate concrete classes but access them via the interface defined
by the abstract class

42
Abstract classes act as placeholders for
other classes
• Abstract classes can also contain common methods that can be used
by all derivations.
• This means that I can have the controller contain Students. The
reference type used will be Student.
• The compiler can check that anything referred to by this Student
reference is, in fact, a kind of Student.

43
Classes (III)
• Inheritance relationships are known as is-a relationships
• Undergraduate IS-A Student

• This phrase is meant to reinforce the concept that the subclass represents
a more refined, more specific version of the superclass
• If need be, we can treat the subclass as if it IS the superclass.
• It has all the same attributes and all the same methods as the superclass

• so code that was built to process the superclass can equally

apply to the subclass

44
Visibility
• Since the objects are responsible for themselves, there are many things they do
not need to expose to other objects.
• Earlier, we mentioned the concept of the public interface—those methods that
are accessible by other objects.
• In object-oriented systems, the main types of accessibility are:
• Public—Anything can see it.
• Protected—Only objects of this class and derived classes can see it.
• Private—Only objects from this class can see it.

45
Classes (IV)
• Classes can control the accessibility of the features of their objects

• That is they can typically specify whether an attribute or method has an accessibility of
public, protected, or private.

• This ability to hide features of a class/module is referred to as

• encapsulation or information hiding;

46
Encapsulation
• The visibility leads to the concept of encapsulation.
• Encapsulation has often been described simply as hiding data.
• Objects generally do not expose their internal data members to the outside
world (that is, their visibility is protected or private).
• But encapsulation refers to more than hiding data.
• In general, encapsulation means any kind of hiding.
• In the example, the instructor did not know which were the regular
students and which were the graduate students. The type of student is
hidden from the instructor (we are encapsulating the type of student).
• however, encapsulation is a topic that is a very important concept
and is broader than just data hiding, as we will discuss later in the
semester

47
Visibility (Accessibility) continued
• Assume

• Object A is an instance of class X

• Object B is an instance of class Y which is a subclass of X;

• Object C is an instance of class Z which is unrelated to X and Y

• UML Model of Previous Statements

X Z A: X B: Y

C: Z

48
Visibility (Accessibility) continued
• Public visibility of a feature of class X means that A, B and C can access that feature

• Protected visibility of a feature of class X means that A and B can access the feature but C
cannot.

• Private visibility of a feature of class X means that only A can access the feature

• Note: these are the general definitions; different programming languages implement these
accessibility modifiers in different ways

• Consult the documentation for details specific to your favorite OO programming

language

49
Polymorphism
• Another term to learn is polymorphism.
• In object-oriented languages, we often refer to
objects with one type of reference that is an
abstract class type.
• However, what we are actually referring to are
specific instances of classes derived from their
abstract classes.
• Thus, when we tell the objects to do something
conceptually through the abstract reference, we
get different behavior, depending upon the specific
type of derived object we have.
• Polymorphism derives from poly (meaning many)
and morph (meaning form). Thus, it means many
forms. This is an appropriate name because we
have many different forms of behavior for the same
call.
50
Object-Oriented Programming in Action
• Let’s re-examine the shapes example discussed at the beginning of
the chapter.
• How would we implement it in an object-oriented manner?
• Remember that it has to do the following:
1. Locate the list of shapes in the database.
2. Open up the list of shapes.
3. Sort the list according to some rules.
4. Display the individual shapes on the monitor.
• To solve this in an object-oriented manner, we need to define the
objects and the responsibilities they would have.
51
Using objects in the Shape program
• The objects we would need are:

52
Running the program
• The main program would now look like this:
1. Main program creates an instance of the database object.
2. Main program asks the database object to find the set of shapes
We are interested in and to instantiate a collection object containing all of the shapes
(actually, it will instantiate circles and squares that the collection will hold).
3. Main program asks the collection to sort the shapes.
4. Main program asks the collection to display the shapes.
5. The collection asks each shape it contains to display itself.
6. Each shape displays itself (using the Display object) according to the type of
shape I have.

53
Why this helps handling new requirements?
• Let’s see how this helps to handle new requirements (remember,
requirements always change). For example, consider the following
new requirements:
• Add new kinds of shapes (such as a triangle). To introduce a new
kind of shape, only two steps are required:
 Create a new derivation of Shape that defines the shape.
 In the new derivation, implement a version of the display method that is
appropriate for that shape.
• Change the sorting algorithm. To change the method for sorting the
shapes, only one step is required:
 Modify the method
Bottom line: The object-oriented approach has limited the impact of changing requirements.
54
Encapsulation revisited
• There are several advantages to encapsulation. The fact that it hides
things from the user directly implies the following:
• Using things is easier because the user does not need to worry about
implementation issues.
• Implementations can be changed without worrying about the caller. (Since
the caller didn’t know how it was implemented in the first place, there
shouldn’t be any dependencies.)
• The insides of an object are unknown to outside objects—they are used by
the object to help implement the function specified by the object’s interface.

55
Benefit: reduced side effect
• Finally, consider the problem of unwanted side effects that arise
when functions are changed.
• This kind of bug is addressed effectively with encapsulation.
• The internals of objects are unknown to other objects.
• If we use encapsulation and follow the strategy that objects are
responsible for themselves, then the only way to affect an object will
be to call a method on that object.
• The object’s data and the way it implements its responsibilities are
shielded from changes caused by other objects.

56
Special Object Methods
• We have talked about methods that are called by other objects or
possibly used by an object itself.
• But what happens when objects are created? What happens when
they go away?
• If objects are self-contained units, then it would be a good idea to
have methods to handle these situations.
• These special methods do, in fact, exist and are called constructors
and destructors.

57
Constructors initialize, or set up, an object
• A constructor is a special method that is automatically called when
the object is created.
• Its purpose is to handle starting up the object.
• This is part of an object’s mandate to be responsible for itself.
• The constructor is the natural place to do initializations, set default
information, set up relationships with other objects, or do anything
else that is needed to make a well-defined object.
• All object-oriented languages look for a constructor method and
execute it when the object is created.

58
Constructors initialize, or set up, an object
(Cont.)
• By using constructors properly it is easier to eliminate (or at least
minimize) uninitialized variables.
• This type of error usually occurs from carelessness on the part of the
developer.
• By having a set, consistent place for all initializations throughout your
code (that is, the constructors of your objects) it is easier to ensure
that initializations take place.
• Errors caused by uninitialized variables are easy to fix but hard to find,
so this convention (with the automatic calling of the constructor) can
increase the efficiency of programmers.
59
Destructors clean up an object when it is no
longer needed (when it has been deleted)
• A destructor is a special method that helps an object clean up after itself
when the object goes out of existence; that is, when the object is
destroyed.
• All object-oriented languages look for a destructor method and execute it
when the object is being deleted.
• As with the constructor, the use of the destructor is part of the object’s
mandate to be responsible for itself.
• Destructors are typically used for releasing resources when objects are no
longer needed.
• Since Java has garbage collection (auto-cleanup of objects no longer in
use), destructors are not as important in Java as they are in C++.

60
One benefit of superclasses
• Treat all instances of a superclass-subclass hierarchy as if they were all instances of the
superclass even if some are instances of subclasses

• Example

• Suppose we have the classes, Undergraduate, MastersStudent and PhDStudent in a

software system

• Problem: We may have a need for acting on all instances of these three classes at once, for
instance, storing them all in a collection, sorting by last name and displaying a roster of the
entire university

• Solution: Make all three of these classes a subclass of the class Student; You can then add all
of the students to a single collection and treat them all the same

61
Example rendered in UML

List * Student

Undergraduate MastersStudent PhDStudent

Note: UML Notation will be discussed in Chapter 2

62
Another benefit of superclasses
• Not only can you group all instances of an object hierarchy into a single collection, but you can
apply the same operations to all of them as well

• In our example, any method defined in the superclass, Student, can be applied to all instances
contained in our collection (the List of Students)

• On the following slide:

• Student has a method called saySomething() which is overridden by each subclass to say
something different

• Yet look how clean the code is…

63
 1 import java.util.LinkedList;
2 import java.util.List;
3
4 public class Test {
5
6 public static void main(String[] args) {
7
8 List<Student> students = new LinkedList<Student>();
9
10 students.add(new Undergraduate("Bilbo Baggins"));
11 students.add(new MastersStudent("Aargorn"));
12 students.add(new PhDStudent("Gandalf the White"));
13
14 for (Student s: students) {
15 System.out.println("" + s);
16 }
17
18 System.out.println();
19
20 for (Student s: students) {
21 s.saySomething();
22 }
23
24 }
25
26 } 64
27
The True Power: Clean Code!
• The most powerful code in the previous example was
for (Student s: students) {
s.saySomething();
}
• Why?

• You can add as many subclasses to the Student hierarchy as you want and this code
never has to change!

• It doesn’t even have to be recompiled (demo)

• Indeed, given the right techniques, a server running this code doesn’t even need to be
“brought down”; the new subclass can be dynamically loaded and this code will
recognize instances of that subclass and do the right thing

65
Summary
• In this chapter, we have shown how object orientation helps us
minimize consequences of shifting requirements on a system and
how it contrasts with functional decomposition.
• We covered a number of the essential concepts in object-oriented
programming and have introduced and described the primary
terminology. These are essential to understanding the concepts in the
rest of this course.

Reference
A. Shalloway and J. Trott, Design Patterns Explained: A New Perspective on Object-Oriented Design,
2nd edition, Addison-Wesley, 2004, ISBN-13: 978-0321247148. ISBN-10: 9780321247148

66