Chapter Three

Understanding the Basics :Object Oriented Concepts

1
 Contents

 OO concepts from structured point of view

 Abstraction, Encapsulation and information hiding
 Inheritance, Association and Aggregation
 Collaboration
 Persistence
 Coupling and Cohesion
 Polymorphism
 Interfaces and Components
 Patterns

2
 OO concepts from structured point of view

The four basic OO concepts

1) Class
A class is a software abstraction of an object, effectively, a template from
which objects are created.
A class is abstract and an object is concrete.
It gives the blueprint or the description of the objects that can be created from it.
Creation of an object as a member of a class is called instantiation. Thus, an object is
an instance of a class
2) Object
Is a real-world element in an object–oriented environment that may have a physical or
a conceptual existence. E.g. person, place, thing, event, concept, screen, or report
3
 Con’d
3) Attributes
Is equivalent to a data element in a record.
Classes have responsibilities, the things they know and do. Attributes are the things
classes know.
4) Methods
Can be thought of as either a function or procedure.
Methods are the things classes do.
There are two types of attributes and method
Instance attributes: applicable to a single object
Static attributes: applicable to all instances of a single class
Instance methods: operate on a single instance
Static methods: operate on all instances
4
Con’d

5
 Abstraction
Process of including features, attributes and methods that are of interest to your
application and ignore the rest.
It is an analysis issue that deals with what a class knows or does
People often say abstraction is the act of painting a clear box around something: you
are identifying what it does and does not do.
For example, consider the abstraction of a person. From the point of view of a
university, it needs to know the person's name, address, telephone number, social
security number, and educational background. From the point of view of the police,
they need to know a person's name, address, phone number, weight, height, hair
color, eye color, and so on. It is still the same person, just a different abstraction,
depending on the application at hand.
OO systems abstract only what they need to solve the problem at hand.
6
 Encapsulation
Encapsulation is a design issue that deals with how functionality is
compartmentalized within a system.
You should not have to know how something is implemented to be able to use it.
The implication of encapsulation is that you can build anything anyway you want,
and then you can later change the implementation and it will not affect other
components within the system.
People often say encapsulation is the act of painting the box black: you are
defining how something is going to be done, but you are not telling the rest of the
world how you are going to do it.
In other words you are hiding the details of the implementation of an item from
the users of that item.
 Con’d

For example, consider your bank. How does it keep track of your account
information, on a mainframe, a mini, or a PC? What database does it use?
What operating system? It does not matter, because it has encapsulated the
way in which it performs account services.
You just walk up to a teller and initiate whatever transactions you want. By
hiding the details of the way it has implemented accounts, your bank is free
to change that implementation at any time, and it should not affect the way
services are provided to you.
 Information Hiding
To make your applications maintainable, you want to restrict access to data
attributes and some methods.
The basic idea is this: if one class wants information about another class, it
should have to ask for it, instead of taking it. When you think about it, this is
exactly the way the real world works.
If you want to learn somebody's name, what would you do? Would you ask the
person for his name, or would you steal his wallet and look at his ID? By
restricting access to attributes, you prevent other programmers from writing
highly coupled code.
When code is highly coupled, a change in one part of the code forces you to
make a change in another, and then another, and so on.
9
 An example
Figure below depicts the driver's interface for a car.
The abstraction is how you work with the wheel, pedals, and gearshift to drive a
car.
Encapsulation allows various carmakers to provide a consistent interface,
although each brand of car is built differently.
 Information hiding is represented by the fact that although the oil is kept at a
specific pressure within the engine the driver does not know what the exact
pressure is. In other words, information about the oil is hidden from the user.

10
 Inheritance
Similarities often exist between different classes.
Two or more classes often share the same attributes and/or the same methods.
 Because you do not want to have to write the same code repeatedly, you want a
mechanism that takes advantage of these similarities.
Inheritance is that mechanism. Inheritance models "is a", "is kind of", and "is
like" relationships, enabling you to reuse existing data and code easily.
For example, students have names, addresses, and telephone numbers, and they
drive vehicles. At the same time, professors also have names, addresses, and
telephone numbers, and they drive vehicles.

11
 Con’d
With inheritance, you define a new class that encapsulates the similarities between
students and professors. This new class would have the attributes name, address, and
phoneNumber, and the method driveVehicle.
Because you need to name all our classes, you need to ask yourself what this collection
of data and functionality describes. In this case, I think the name Person is fitting.
Once you have the class Person defined, you then make Student and Professor inherit
from it.
You would say Person is the superclass of both Student and Professor, and Student and
Professor are the subclasses of Person.
 Everything that a superclass knows or does, the subclass knows or does free without
writing extra code.
12
 Modeling Inheritance
The UML modeling notation for inheritance, a line with a closed arrowhead. The
way you would read the diagram is "B inherits from A." In other words, B is a direct
subclass of A and A is the direct super class of B.

The UML modeling notation for inheritance.

Modeling the concept that Professor and Student inherit
from Person. 13
 Types of Inheritance
 Single Inheritance: when a class
inherits from only one other class,
we call this single inheritance

 Multiple Inheritance: when a class

inherits from two or more other
classes

 Multilevel Inheritance : A subclass derives

from a super-class which in turn is derived
from another class and so on.
14
14
Hierarchical Inheritance : A class has a
number of subclasses each of which may
have subsequent subclasses, continuing
for a number of levels, so as to form a
tree structure.

Hybrid Inheritance : A combination of

multiple and multilevel inheritance so as
to form a lattice structure.
 Inheritance Tips and Techniques

Look for similarities

Look for existing classes
Follow the sentence rule
Inherit everything.

16
 Abstract and Concrete Classes
The main difference between abstract classes and concrete classes
is that objects are instantiated (created) from concrete classes, but
not from abstract classes.
Abstract classes are model when you need to create a class that
implements common feature from two or more classes.
If the class Vehicle is marked as abstract, whereas Airplane and
Car are not. We say Vehicle is an abstract class, whereas Airplane
and Car are both concrete classes.
Your software will instantiate airplane and car objects but will
never create vehicle objects
17
 Association
• A relationship or link between instances (or objects) of
classes.
• Exist between objects
– Students TAKE courses, professors TEACH courses
– Criminals ROB banks etc…
• Identify the relationship and describe it
– Students TAKE courses
• How many students?, How many courses? Etc
– Identify the Cardinality
• Multiplicity
18
 Multiplicity in Association
We can indicate the multiplicity of an association by adding multiplicity
adornments to the line denoting the association.
The example indicates that a Student has one or more Instructors:
Example:

19
19
 Aggregation
Sometimes an object is made up of other objects.
 For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps,
and so on.
A delivery shipment contains one or more packages.
A project team consists of two or more employees. These are all examples of the concept
of aggregation, which represents "is part of" relationships.
An engine is part of a plane, a package is part of a shipment, and an employee is part of a
team.
Composition is a strong form of aggregation in which the "whole" is completely
responsible for its parts and each "part" object is only associated to the one whole object.
For example, at any given time, an engine is part of one and only one airplane (otherwise,
you have a serious problem).
20
 Example

ProductGroup is composed of Products. This means that if a ProductGroup is

destroyed, the Products within the group are destroyed as well.
PurchaseOrder is an aggregate of Products. If a PurchaseOrder is destroyed, the
Products still exist.
21
 Aggregation tips and techniques

Apply the sentence rule

The whole should manage the part
You should be interested in the part
Show multiplicity and roles
Aggregation is inherited

22
 Dependency
The most common kind of dependency relationship is the connection between a
class that only uses another class as a parameter to an operation.
For example, Figure shows a set of classes drawn from a system that manages the
assignment of students and instructors to courses in a university. This figure
shows a dependency from CourseSchedule to Course, because Course is used in
both the add and remove operations of CourseSchedule.

23
 Collaboration & Messages
Classes often need to work together to fulfill their responsibilities.
Actually, it is typically the objects and the instances of the classes that are working
together.
Collaboration occurs between objects when one object asks another for
information or to do something.
For example, an airplane collaborates with its engines to fly. For the plane to go
faster, the engines must go faster. When the plane needs to slow down, the engines
must slow down. If the airplane did not collaborate with its engines, it would be
unable to fly.
Objects collaborate with one another by sending each other messages.
 A message is either a request to do something or a request for information.

24
 Persistence
Persistence focuses on the issue of how to make objects available for
future use of your software. In other words, how to save objects to
permanent storage.
To make an object persistent, you must save the values of its attributes to
permanent storage (such as a relational database or a file) as well as any
information needed to maintain the relationships (aggregation, inheritance,
and association) with which it is involved.
In other words you need to save the appropriate properties to permanent
storage.
In addition to saving objects, persistence is also concerned with their
retrieval and deletion.
25
 Con’d

From a development point of view, there are two types of objects: persistent objects
that stick around and transient objects that do not.
For example, a Customer is a persistent class. You want to save customer objects into
some sort of permanent storage so you can work with them again in the future.
A customer editing screen, however, is a transient object. Your application creates the
customer-editing screen object, displays it, and then gets rid of it once the user is done
editing the data for the customer with whom he or she is currently dealing.

26
 Persistence tips and techniques

[Link]/domain classes are usually persistent. You are naturally going to need to keep a
permanent (persistent) record of the instances of real-world classes like Student, Professor,
and Course.
[Link]-interface classes are usually transitory. User-interface classes (screens and reports)
are usually transitory.
 Screens are created and displayed when needed, and then once they are no longer in use,
they are destroyed (removed from memory).
 Report classes are created, they gather the data they need, manipulate the data, and then
output the data. Once this is done, the report object is usually destroyed as well.
3. You need to store both attributes and associations. When an object is written to disk,
you obviously need to store the value of its attributes. However, you must also store
information about any relationships/associations with which the object is involved.

27
 Coupling
Coupling is a measure of how two items, such as classes or methods, are interrelated.
When one class depends on another class, we say they are coupled.
 When one class interacts with another class, but does not know any of the
implementation details of the other class, we say they are loosely coupled.
 When one class relies on the implementation (that is, it directly accesses the data
attributes of the other), we say they are tightly coupled.
The basic problem is when two classes are tightly coupled; a change in one often
requires a change in the other. This, in turn, could require a change in another class, and
then another, and then another, and so on.
Tight coupling is one of the main reasons such a large maintenance burden exists.

28
 Coupling Tips and Techniques

Avoid high coupling if you can

Document high coupling thoroughly

29
 Cohesion
Cohesion is a measure of how much an item, such as a class or method, makes sense.
A good measure of the cohesiveness of something is how long it takes to describe it in
one sentence: the longer it takes, the less cohesive it likely is.
You want to design methods and classes that are highly cohesive. In other words, it
should be very clear what a method or class is all about.
A method is highly cohesive if it does one thing and one thing only.
For example, in the class Student you would have methods to enroll a student in a
seminar and to drop a student from a seminar. Both of these methods do one thing and
one thing only. You could write one method to do both these functions, perhaps called
changeSeminarStatus.
A highly cohesive class represents one type of object and only one type of object.

30
 Cohesion Vs Coupling

 A good design is the one that has low coupling.

Coupling is measured by the number of
relations between the modules.
31
 Polymorphism
Originally a Greek word that means the ability to take multiple forms.
An individual object may be one of several types.
For example, a John Smith object may be a student, a registrar, or even a professor.
Should it matter to other objects in the system what type of person John is? It would
significantly reduce the development effort if other objects in the system could treat
people objects the same way and not need to have separate sections of code for each
type.
The concept of polymorphism says you can treat instances of various classes the same
way within your system.
The implication is you can send a message to an object without first knowing what type
it is and the object will still do "the right thing," at least from its point of view.
32
 Con’d
Is

Polymorphism allows objects with different internal structures to have a

common external interface.
Polymorphism allows us to perform a single action in different ways.
If one task is performed in different ways, it is known as polymorphism.

33
 Interfaces and Components
Interfaces
An interface is the definition of a collection of one or more methods, and zero or
more attributes. Interfaces ideally define a cohesive set of behaviors.
Interfaces are implemented by classes and components.
 To implement an interface, a class or component must include the methods
defined by the interface.
For example, the class Student implements the Serializable interface and the
Searchable interface. To implement the Searchable interface, Student must
include a method called find, which takes criteria as a parameter.
Interfaces are a powerful method for ensuring loose coupling. They allow a class
to participate in a common set of functionality without another class having to
know anything about it except that it supports that interface.
34
 Con’d
Components
A component is a modular, extensible unit of independent deployment that has
contractually specified interface(s) and explicitly defined dependencies, if any. Ideally,
components should be modular, extensible, and open.
Components, like classes, implement interfaces. A component's interfaces define its
access points.
Components are typically implemented as collections of classes, ideally classes that
form a cohesive subset of your overall systems.
Components are typically heavyweights and could even be thought of as large classes or
even subsystems.
For example, a database could be a component or the collection of business/domain
classes that implement the behaviors required to implement people within your
35
application could be a component.
 Patterns
A pattern is a solution to a common problem taking relevant forces into
account, effectively supporting the reuse of proven techniques and
approaches of other developers.
Several flavors of patterns exist, including analysis patterns, design
patterns, and process patterns.
Analysis patterns describe a solution to common problems found in the
analysis/business domain of an application,
Design patterns describe a solution to common problems found in the
design of systems, and
Process patterns address software process- related issues
36
Thank y u…!