Chapter 2

Object-Oriented Concepts
This chapter discusses the following topics:

Structured and object-oriented approaches

Classes and objects
Encapsulation and data hiding
Class association
Object interaction
Inheritance
Abstract classes
Polymorphism
Accessibility of class members
Unified Modelling Language (UML).

2.1 Object Orientation & C#

C#, like Java, is an object-oriented language. It is not a procedural language like C or
Pascal. That means, to learn C# you need to know object-oriented concepts, which is
the topic of this chapter. Object-orientation includes concepts such as classes and
objects, encapsulation, object interaction and message passing, class hierarchy and
inheritance, polymorphism and function and operator overloading.
This chapter will present the main object-oriented concepts while chapter 11 will
introduce object-oriented programming.

2.2 Structured & Object-Oriented Approaches

There are essentially two main approaches used in systems development: structured
and object-oriented. The structured approach has a long history and is well

2-2 Chapter 2
documented. The object-oriented approach is relatively new but promises to offer
benefits such as encapsulation and software reuse.
The structured approach uses techniques such as Entity Relationship Diagram (ERD)
for modelling data, Data Flow Diagram (DFD) for modelling processes, and the
Structure Chart (SC) for decomposing system functionality into a hierarchy of
functions, where higher-level functions represent general functions and lower-level
functions represent detailed functions. The emphasis in this approach is on processes
(i.e., functions). Data modelling is considered secondary. This approach uses CASE
tools such as System Architect and Visible Analyst.
The object-oriented approach uses techniques such as Class diagrams for modelling
data, Use case diagrams for modelling system functionalities, and Sequence and
Collaboration diagrams to model object interactions. The emphasis in this approach is
on data modelling first and functions (processes) second. This approach uses CASE
tools such as Enterprise Architect and Rational Rose.
The object-oriented approach offers several benefits over the structured approach,
some of which are:
1. It models real systems more naturally since systems in the real world are
simply collections of objects that interact with one another.
2. It emphasizes on data, which is less volatile than functions. By emphasizing on
data, the effects of system changes are minimized. This is especially important
especially in maintenance. (The structured system emphasizes on functions
first and then on the data that the functions need.)
3. It encapsulates data and methods (functions) within a single entity called
object. That means, only methods associated with the object class can
manipulate the data in the object. Methods outside the class are forbidden to
access the objects data. This hiding of data provides more security. (In the
structured approach, data and methods are separated. Typically, many
functions share the same data and this causes problems, for example, when
one function modifies the shared data in some unacceptable manner.)
4. It supports software reuse by allowing components to be built and reused in
several applications. This reduces system development cost and time. Reuse
also improves the quality of the system delivered. This is because only fully
tested and deployed components are reused.
5. It supports method and operator overloading. Method overloading means
overloading the behavior of a method in a class such that it behaves differently
at different times depending on the number and type of parameters passed.
Operator overloading means overloading the meaning of the operator such as

Object-Oriented Concepts 2-3

when a + operator is used to define both the addition of two simple variables
and the addition of two array variables. These features provide flexibility.
6. It supports object hierarchy and inheritance. Objects are arranged in a
hierarchy so that lower-level objects can inherit the properties and behaviors of
higher level objects. This provides a natural way of modeling a system.
Inheritance allows software to be reused.
7. It supports polymorphism, i.e., it allows objects in a class hierarchy (all
having the same method name) to behave differently. Any conflict arising is
resolved at runtime.
8. It supports good design criteria such as modularity, cohesion and low coupling
(decoupling).
9. It is supported by modeling languages such as the Unified Modeling Language
(UML). UML can be used to model complex systems, e.g., web-based,
manufacturing and real-time systems.
10. It is supported by CASE tools (e.g., Enterprise Architect, Rational Rose).
These tools support the development and maintenance of object-oriented
systems.

2.3 Classes & Objects

A class represents a collection of objects that have similar properties they have the
same attributes and operations. For example, all employees in the Employee class
will have attributes such as employee number, name and salary and they will need to
do similar things such as modifying employee information and calculating salary.
The attributes are also known as data or variables while the operations are also
known as behaviour, functions, methods or services. The data and methods of a class
are its members.
An object is an instance of a class. There can be any number of objects belonging to a
class. For example, the Employee class may have Miriam, Wong, Kamala and
Susan as objects (Figure 2.1).
Figure 2.1: Class and its objects
Class

Employee

Class Objects

Miriam

Wong

Kamala

Susan

2-4 Chapter 2
A box diagram with three partitions is usually used to show the class details. The top
partition shows the class name; the middle partition, the attributes; and the bottom
partition, the operations. Figure 2.2 shows the Employee class and its attributes (data)
and methods (operations).
Figure 2.2: An object with attributes and methods
Employee

Object's name

EmpNo
EmpName
Salary

Object's attributes

ModifyInfo
ComputeSalary

Object's methods

Objects have states. The state of an object is determined by the values of its attributes.
By changing the values of attributes a method can change the state of the object. For
example, an employees state can be changed from full time to part time by changing
the value of the attribute, say status.

2.4 Encapsulation
An object encapsulates (i.e., packages) both data (attributes) and methods (operations).
The data describes the attributes of the object while the methods describe its behaviour.
Only methods within the object are allowed to modify the objects attributes as Figure
2.3 illustrates.
Figure 2.3: Encapsulation of data and methods in a class
Method

Method

Method

DATA

DATA

Method

Method

DATA

DATA

Method

Method

Method

The implementation details of an object are hidden from other objects. That means,
external methods are not allowed to access and modify its data. This is a desirable
property as it allows an object to shield itself from externally induced errors.

Object-Oriented Concepts 2-5

The class mechanism allows objects to hide their data from the outside world. This is
one of the strengths of object-oriented programming (OOP).

2.5 Class Association

Class association tells how classes in a system are organized. It specifies the business
rules. The term multiplicity is used to refer to these rules. It tells how many instances
of one object are associated with a single instance of another object. (The idea is
similar to the cardinality rule in ERD.) Figure 2.4 shows several examples of
multiplicities.
Figure 2.4: Multiplicities in class associations

Person

Teacher

Teller

Staff

Student

Tricycle

Egg Box

has
1

1
teaches

*
has

1..*
works on

0,1
takes

3..5
has

3
holds

6,12

Identity Card

Student

One-to-one

One-to-many

Customer

One-to-one or more

Project

One-to-zero or one

Course

One-to-three through five

Wheel

One-to-three

Egg

One-to-six or twelve

2-6 Chapter 2
The figure shows that one Person can have only one IdentityCard; one
Teller can serve one or more customers; one Student can take from 3 to 5
courses; and one EggBox can hold 6 or 12 eggs.

2.6 Object Interaction

Objects in a system interact by passing/sending messages. Sending messages is
equivalent to invoking methods. The messages can include parameters. Figure 2.5
illustrates the idea of message passing.
Figure 2.5: Message passing
Order
ONo
ODate
PId
CustId

Inventory

GetName(PId)

PId
PName
Price
Stock
GetName(PId)

2.7 Class Hierarchy & Inheritance

Classes in a system can be arranged in a hierarchy. For example, the classes
Person, Student and Employee can be arranged in a hierarchy as shown in
Figure 2.6. The Person class is called the super class (also called base or parent
class) while the Student and Employee classes are called subclasses (also called
derived or child classes). This is an example of a two-level hierarchy.

Object-Oriented Concepts 2-7

Figure 2.6: A two-level class hierarchy

Person

Student

Base class

Employee

Derived classes

Inheritance is the property that when classes are arranged in a hierarchy, the derived
classes inherit the properties - attributes and behaviours - of the base class. The
derived classes automatically inherit the properties of the base class. That means
properties that are defined in the base class need not be defined again in the derived
classes. Only additional properties that are needed are defined in the derived classes.
Inheritance thus promotes software reuse.
To illustrate, lets refer to Figure 2.6.The derived classes Student and Employee
both inherit all the properties of the base class Person, i.e., all the properties of
Person are automatically available to Student and Employee.
Figure 2.7 further illustrates the concept of inheritance. Let's suppose the classes
Person, Student and Employee have the following properties:
Class
Person
Student
Employee

Attributes
Name, Age, Sex
StudNo, Course
EmpNo, Pay

Figure 2.7: Inherited attributes and methods

Methods
Initialize, Add, Modify
ChangeInfo
ComputePay

2-8 Chapter 2

In this case, Student and Employee inherit all the properties of Person which
include the attributes Name, Age and Sex and the methods Initialize, Add
and Modify.
A class hierarchy can have multiple levels. For example, Figure 2.8 shows a three-level
class hierarchy.
The idea of inheritance is the same for multilevel hierarchy. For example, in this figure,
Local employee inherits all the properties of Employee which, in turn,
inherits all the properties of Person. That means, Local employee inherits all
the properties of Employee (directly) and all the properties of Person
(indirectly).

Object-Oriented Concepts 2-9

Figure 2.8: A three-level class hierarchy
Base class

Person

Full-time
student

Derived/Base
classes

Employee

Student

Part-time
student

Local
employee

Foreign
employee

Derived
classes

Abstract Classes
An abstract class is one that cannot be instantiated, i.e., it has no objects. It is a
generic class. It is useful for modelling elements - attributes and operations - that are
common to several subclasses. The common elements can be factored and put in an
abstract class.
The abstract class can be useful for modifying or reusing software. For example, a
patient can be an in-patient or out-patient (Figure 2.9). If we want to modify the way
Patient members are implemented in the system, it is neater and more efficient to
do this once in the Patient class than in both the InPatient and OutPatient
classes.
Figure 2.9: Abstract class
Patient
PatientId
Delete()

OutPatient

InPatient

DateOfVisit

BedCharges

Delete()

Delete()

2-10 Chapter 2

Note that all three classes have the Delete operation. This occurs as a generic
operation in the Patient class, and is then refined in different ways in each of the
subclasses. The Delete operation in the InPatient and OutPatient classes
overrides the Delete operation in the Patient class. That means they will be
implemented in different ways. But because they have the same name, parameters and
results, these differences will not be visible externally.

2.8 Accessibility Of Class Members

Class members (i.e., attributes and methods) can have different levels of accessibility.
Accessibility defines the scope or visibility of members - private, public, internal or
protected. If the scope of a member is private, it can only be accessed from that class;
if the scope is public, it can be accessed from any class including classes from other
projects; if the scope is internal, it can be accessed by any class within the current
project; and if the scope is protected, it can only be accessed by classes in that
hierarchy.
So if you do not members from other class to access, you must declare them as private.
If you want members from other classes (including other projects) to access, you
declare them as public. If you want members from other classes in the current project
to access, you declare them as internal. If you only want members in a class hierarchy
to access, you declare them as protected.
The term access specifier is used to specify the type of access allowed for a class
member. By default, all members of a class are private. So if you dont specify
anything, all the members will be treated as private (i.e., they will not be accessible to
the outside world).
However, for a class to be useful, it must generally allow access to other class
members. In general, most data/variables would be declared as private while most
methods would be declared as public.
Although encapsulation ensures hiding implementation of details, it does not mean
objects from one class cannot invoke methods in another class for needed services. On
the contrary, objects will generally need to invoke methods in other classes. The called
object will perform the requested service or send a message back to the sender if
something is wrong with the request.

Object-Oriented Concepts 2-11

How does an object from one class know what services are provided by objects in
other classes? To do this, a class must provide a published interface. The interface
tells what services the class provides to other classes. Objects from other classes can
access this interface to request for the services they need. For example, if an
Employee object wants to know the name of its department, it can send the EmpNo
to a Dept object which can then get the department name and pass it to the
Employee object.

2.9 Polymorphism
Polymorphism means many forms. This feature allows two or more classes in a class
hierarchy to have the same method name, but each is allowed to behave differently. A
method is said to be polymorphic if it takes different forms (i.e., behaves differently) in
different classes. For example, a class hierarchy may use the method Draw()to draw
a shape. But the shape can be different for different objects a rectangle in one class, a
circle in another class, and a polygon in another class as shown in Figure 2.10.

2.10 Unified Modelling Language

The Unified Modelling Language (UML) is a modelling language for object-oriented
systems. It is not a programming language like Visual Basic or C#. Rather, it is a
language for visualizing, specifying, designing and documenting a software system.
UML is the work of three software scientists: Grady Booch, Ivar Jacobson and James
Rumbaugh. UML has now become the standard language for modelling object-oriented
systems. There are several CASE tools which support UML such as Enterprise
Architect and Rational Rose.
Figure 2.10: Polymorphism

2-12 Chapter 2

Exercise
2.1 Why is an object-oriented system superior to a structured system?
2.2 Identify three classes that are appropriate for a library information system. For
each class identified, list the attributes and operations that might be needed for
each of these class objects.
2.3 What do you understand by the term encapsulation? Why is it a desirable feature
in an object-oriented system?
2.4 Why do objects in a system interact with one another? How is this interaction
achieved?
2.5 List some of the benefits of class inheritance.
2.6 What is an abstract class and why do you need it?
2.7 What is polymorphism and why do you need it?
2.8 What is UML? How does it help in systems development?