0% found this document useful (0 votes)
67 views47 pages

Reviewoo

Uploaded by

aziz spam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
67 views47 pages

Reviewoo

Uploaded by

aziz spam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 47

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

You might also like