Programming

Paradigms
CSI2120

Jochen Lang
EECS, University of Ottawa
Canada
 Review of Object-oriented
Programming
• Acknowledgement
– These slides are a barely modified version of the slides for
Chapter 2, Object-Oriented Software Engineering:
Practical Software Development using UML and Java by
Tim Lethbridge and Robert Laganière

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 1. What is Object Orientation?

• Procedural paradigm:
– Software is organized around the notion of procedures
– Procedural abstraction
• Works as long as the data is simple
– Adding data abstractions
• Groups together the pieces of data that describe some
entity
• Helps reduce the system’s complexity.
– Such as records and structures

• Object oriented paradigm:

– Organizing procedural abstractions in the context of data
abstractions

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Object Oriented Paradigm

• An approach to the solution of problems in which all

computations are performed in the context of objects.

– The objects are instances of classes, which:

• are data abstractions
• contain procedural abstractions that operate on the
objects

– A running program can be seen as a collection of objects

collaborating to perform a given task

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 A View of the Two Paradigms

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 2 Classes and Objects

• Object
– A chunk of structured data in a running software system

– Has properties
• Representing its state

– Has behaviour
• How it acts and reacts
• May simulate the behaviour of an object in the real world

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Objects

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Classes

• A class:
– A unit of abstraction in an object oriented (OO) program

– Represents similar objects

• Its instances

– A kind of software module

• Describes its instances’ structure (properties)
• Contains methods to implement their behaviour

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Is Something a Class or an Instance?

– Something should be a class if it could have instances

– Something should be an instance if it is clearly a single member
of the set defined by a class
• Film
– Class; instances are individual films.
• Reel of Film:
– Class; instances are physical reels
• Film reel with serial number SW19876
– Instance of ReelOfFilm
• Science Fiction
– Instance of the class Genre.
• Science Fiction Film
– Class; instances include ‘Star Wars’
• Showing of ‘Star Wars’ in the Phoenix Cinema at 7 p.m.:
– Instance of ShowingOfFilm

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Common Approach to Naming Classes

– Use capital letters

• E.g. BankAccount not bankAccount

– Use singular nouns

– Use the right level of generality

• E.g. Municipality, not City

– Make sure the name has only one meaning

• E.g. ‘bus’ has several meanings

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Bjarne Stroustrup: What is so great
about classes?
• “Classes are there to help you organize your code and to
reason about your programs”.
• “A class is the representation of an idea, a concept, in the
code. An object of a class represents a particular example
of the idea in the code”.
– “Without classes, a reader of the code would have to guess
about the relationships among data items and functions -
classes make such relationships explicit and "understood" by
compilers. With classes, more of the high-level structure of
your program is reflected in the code, not just in the
comments”. [emphasis added]
Source: http://www.stroustrup.com/bs_faq.html#class, accesed Jan. 2019

CSI2120 Programming Paradigms

 3 Instance Variables

• Variables defined inside a class corresponding to data

present in each instance
– Also called fields or member variables
– Attributes
• Simple data
• E.g. name, dateOfBirth
– Associations
• Relationships to other important classes
• E.g. supervisor, coursesTaken

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Variables vs. Objects

• A variable
– Refers to an object
– May refer to different objects at different points in time
• An object can be referred to by several different variables at
the same time
• Type of a variable
– Determines what classes of objects it may contain

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Class variables

• A class variable’s value is shared by all instances of a

class.
– Also called a static variable
– If one instance sets the value of a class variable, then all the
other instances see the same changed value.
– Class variables are useful for:
• Default or ‘constant’ values (e.g. PI)
• Lookup tables and similar structures
– Caution: do not over-use class variables

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 4 Methods, Operations and
Polymorphism
• Operation
– A higher-level procedural abstraction that specifies a type of
behaviour
– Independent of any code which implements that behaviour
• E.g. calculating area (in general)

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Methods, Operations and
Polymorphism
• Method
– A procedural abstraction used to implement the behaviour of
a class
– Several different classes can have methods with the same
name
• They implement the same abstract operation in ways
suitable to each class
• E.g. calculating area in a rectangle is done differently
from in a circle

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Polymorphism

• A property of object oriented software by which an abstract

operation may be performed in different ways in different
classes.
– Requires that there be multiple methods of the same name
– The choice of which one to execute depends on the object
that is in a variable
– Reduces the need for programmers to code many if-else or
switch statements

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 5 Organizing Classes into Inheritance
Hierarchies
• Superclasses
– Contain features common to a set of subclasses
• Inheritance hierarchies
– Show the relationships among superclasses and subclasses
– A triangle shows a generalization in UML
• Inheritance
– The implicit possession by all subclasses of features defined
in its superclasses

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 An Example Inheritance Hierarchy

• Inheritance
– The implicit possession by all subclasses of features defined
in its superclasses

See in Umple

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 The Isa Rule

• Always check generalizations to ensure they obey the isa

rule
– “A checking account is an account”
– “A village is a municipality”
• Should ‘Province’ be a subclass of ‘Country’?
– No, it violates the isa rule
• “A province is a country” is invalid!

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 A Possible Inheritance Hierarchy of
Mathematical Objects

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Make Sure all Inherited Features Make
Sense in Subclasses

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 6 Inheritance, Polymorphism and
Variables

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Some Operations in the Shape
Example

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Abstract Classes and Methods

• An operation should be declared to exist at the highest

class in the hierarchy where it makes sense
– The operation may be abstract (lacking implementation) at
that level
– If so, the class also must be abstract
• No instances can be created
• The opposite of an abstract class is a concrete class
– If a superclass has an abstract operation then its subclasses
at some level must have a concrete method for the operation
• Leaf classes must have or inherit concrete methods for
all operations
• Leaf classes must be concrete

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Overriding

• A method would be inherited, but a subclass contains a

new version instead
– For restriction
• E.g. scale(x,y) would not work in Circle
– For extension
• E.g. SavingsAccount might charge an extra fee following
every debit
– For optimization
• E.g. The getPerimeterLength method in Circle is much
simpler than the one in Ellipse

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Methods and Inheritance

• How a decision is made about which method to run

1. If there is a concrete method for the operation in the current
class, run that method.
2. Otherwise, check in the immediate superclass to see if
there is a method there; if so, run it.
3. Repeat step 2, looking in successively higher superclasses
until a concrete method is found and run.
4. If no method is found, then there is an error
• In Java and C++ the program would not have compiled

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Dynamic Binding

• Occurs when decision about which method to run can only

be made at run time
– Needed when:
• A variable is declared to have a superclass as its type,
and
• There is more than one possible polymorphic method
that could be run among the type of the variable and its
subclasses

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 7 Concepts that Define Object
Orientation
• The following are necessary for a system or language to be
OO
– Identity
• Each object is distinct from each other object, and can be
referred to
• Two objects are distinct even if they have the same data
– Classes
• The code is organized using classes, each of which
describes a set of objects
– Inheritance
• The mechanism where features in a hierarchy inherit from
superclasses to subclasses
– Polymorphism
• The mechanism by which several methods can have the
same name and implement the same abstract operation.

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Other Key Concepts

• Abstraction
– Object -> something in the world
– Class -> objects
– Superclass -> subclasses
– Operation -> methods
– Attributes and associations -> instance variables
• Modularity
– Code can be constructed entirely of classes
• Encapsulation
– Details can be hidden in classes
– This gives rise to information hiding:
• Programmers do not need to know all the details of a class

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Bjarne Stroustrup: What is "OOP" and
what's so great about it?
• “Object-oriented programming is a style of programming
originating with Simula (…) relying of encapsulation,
inheritance, and polymorphism.”
• “It means programming using class hierarchies and virtual
functions to allow manipulation of objects of a variety of
types through well-defined interfaces and to allow a
program to be extended incrementally through derivation.”

Source: http://www.stroustrup.com/bs_faq.html#class, accesed Jan. 2019

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 The Origins of Java

• Origin
– The first object oriented programming language was Simula-67
• designed to allow programmers to write simulation
programs
• 1980s
– Smalltalk was developed at Xerox PARC
• New syntax, large open-source library of reusable code,
bytecode, platform independence, garbage collection.
– C++ was developed by B. Stroustrup at ATT Labs
• Started in 1979. The initial version was called "C with
Classes".
• 1990s
– Sun Microsystems started a project to design a language that
could be used in consumer ‘smart devices’: Oak
• When the Internet gained popularity, Sun seized the
opportunity and renamed the new language Java. It was
first presented at the SunWorld ’95 conference.

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Appendix

• Review of Java in a Few Slides

CSI2120 Programming Paradigms

 Java documentation

• Looking up classes and methods is an essential skill

– Looking up unknown classes and methods will get you a
long way towards understanding code

• Java documentation can be automatically generated by a

program called Javadoc
– Documentation is generated from the code and its
comments
– You should format your comments as shown in some of the
book’s examples
• These may include embeded html

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Characters and Strings

• Character is a class representing Unicode characters

– More than a byte each
– Represent any world language

• char is a primitive data type containing a Unicode character

• String is a class containing collections of characters

– + is the operator used to concatenate strings

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Arrays and Collections

• Native arrays are of fixed size and lack methods to

manipulate them
• ArrayList is part of the collection framework and is a
growable array to hold a collection of other objects
• Iterators can be used to access members
ArrayList<Integer> numbers = new ArrayList<Integer>();
numbers.addAll(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8));
Iterator<Integer> i = numbers.iterator();
while(i.hasNext())
{
System.out.println(i.next());
}

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Casting

• Java is very strict about types

– If variable v is declared to have type X, you can only invoke
operations on v that are defined in X or its superclasses
• Even though an instance of a subclass of X may be actually
stored in the variable
– If you know an instance of a subclass is stored, then you can
cast the variable to the subclass
E.g. if I know a Vector contains instances of String, I can get
the next element of its Iterator using:
(String)i.next();
To avoid casting you should use generics as in the previous
slide:
ArrayList<String> a; i=a.iterator(); i.next()

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Exceptions

• Anything that can go wrong should result in the raising of

an Exception in Java
– Exception is a class with many subclasses for specific things
that can go wrong
• Use a try - catch block to trap an exception
try
{
// some code
}
catch (ArithmeticException e)
{
// code to handle division by zero
}

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Interfaces

• Like abstract classes, but cannot have executable

statements
– Define a set of operations that make sense in several
classes
– Abstract Data Types
• A class can implement any number of interfaces
– It must have concrete methods for the operations
• You can declare the type of a variable to be an interface
– This is just like declaring the type to be an abstract class
• Important interfaces in Java’s library include
– Runnable, Collection, Iterator, Comparable, Cloneable

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Packages and importing

• A package combines related classes into subsystems

– All the classes in a particular directory

• Classes in different packages can have the same name

– Although not recommended

• Importing a package is done as follows:

– import finance.banking.accounts.*;

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Access control

• Applies to methods and variables

– public
• Any class can access
– protected
• Only code in the package, or subclasses can access
– no modifier (blank)
• Only code in the package can access but not sub-
classes outside package
– private
• Only code written in the class can access
• Inheritance still occurs!

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Threads and concurrency

• Thread:
– Sequence of executing statements that can be running
concurrently with other threads
• To create a thread in Java:
1. Create a class implementing Runnable or create a class
extending Thread
2. Implement the run method as a loop that does something
for a period of time
3. Create an instance of this class
4. Invoke the start operation, which calls run

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Programming Style Guidelines

• Remember that programs are for people to read

– Always choose the simpler alternative
– Reject clever code that is hard to understand
• Stroustrup: “Don't be clever”.
– Shorter code is not necessarily better
• Choose good names
– Make them highly descriptive
– Lethbridge/Laganière: “Do not worry about using long
names”
– Stroustrup: “Don't use overly long names; they are hard to
type, make lines so long that they don't fit on a screen, and
are hard to read quickly.”

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Programming style …

• Comment extensively
– Comment whatever is non-obvious
– Do not comment the obvious
– Comments should be 25-50% of the code
– Stroustrup: “If the comment and code disagree, both are
probably wrong”.
• Organize class elements consistently
– Variables, constructors, public methods then private
methods
• Be consistent regarding layout of code
– Stroustrup: “Such style issues are a matter of personal taste.
Often, opinions about code layout are strongly held, but
probably consistency matters more than any particular style”

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Programming style …

• Avoid duplication of code

– Do not ‘clone’ if possible
• Create a new method and call it
• Cloning results in two copies that may both have bugs
– When one copy of the bug is fixed, the other may be
forgotten

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 Programming style ...

• Adhere to good object oriented principles

– E.g. the ‘isa rule’

• Prefer private as opposed to public

• Do not mix user interface code with non-user interface code

– Interact with the user in separate classes
• This makes non-UI classes more reusable

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

 10 Difficulties and Risks in Object-
Oriented Programming
• Language evolution and deprecated features:
– Java is evolving, so some features are ‘deprecated’ at every
release
– But the same thing is true of most other languages
• Efficiency can be a concern in some object oriented systems
– Java can be less efficient than other languages
• VM-based
• Dynamic binding
• Stroustrup [HOPL-III, 2007]
– “Another problem was that Java encouraged a limited “pure
object-oriented” view of programming with a heavy emphasis
on run-time resolution and a de-emphasis of the static type
system”

© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation