Programming 2


Object-Oriented Programming with Java

Oscar Nierstrasz
double size() {
double total = 0;
for (Shape shape : shapes) {
total += shape.size();
}
return total;
(10,12)
}
(5,9)

(6,6)

(12,3)
(3,3)
P2 — Object-Oriented Programming

Lecturer: Oscar Nierstrasz

Pooja Rani
Assistants: Pascal André, Julius Oeftiger,
Lorenzo Wipfli, Marcel Zauder
WWW: scg.unibe.ch/teaching/p2

2
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

3
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

4
Your Learning Targets

You understand requirements engineering,

designing and implementing object-oriented software
Knowledge
You can understand and create basic UML Diagrams

You understand and can apply various Design Patterns

+
You apply a Test-Driven Development process

Skills
You use your IDE, Debugger efficiently and effectively

You can communicate and work in Teams

5
The Big Picture

EI DA

P1 P2 ESE PSE …

DB MMS

6
Recommended Texts

> Java in Nutshell: 6th edition,

David Flanagan, O’Reilly, 2014.

> An Introduction to Object-Oriented Programming,

Timothy Budd, Addison-Wesley, 2004.

> Object-Oriented Software Construction,

Bertrand Meyer,Prentice Hall, 1997.

> Object Design - Roles, Responsibilities and Collaborations,

Rebecca Wirfs-Brock, Alan McKean, Addison-Wesley, 2003.

> Design Patterns: Elements of Reusable Object-Oriented Software,

Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison Wesley,
Reading, Mass., 1995.

> The Unified Modeling Language Reference Manual,

James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley, 1999
7
Schedule

1. Introduction
2. Object-Oriented Design Principles
3. Design by Contract
4. A Testing Framework
5. Debugging and Tools
6. Iterative Development
7. Advanced Design Lab
8. Inheritance and Refactoring
9. GUI Construction
10.Guidelines, Idioms and Patterns
11.A bit of Smalltalk
12.A bit of C++
13.Guest Lecture — Software-Entwicklung in der Praxis
8
This is a note (a hidden slide). You will find some of these
scattered around the PDF versions of the slides.
 Plagiarism

Don’t copy!
The purpose of
exercises is training.
Copying answers
defeats this purpose!

NB: Plagiarism
is a serious
offense and is
not tolerated. 10
Please consult the U Bern guidelines and regulations:
http://www.unibe.ch/universitaet/organisation/rechtliches/rechtssammlung/
reglemente_richtlinien_weisungen_der_universitaetsleitung/
wissenschaftliche_integritaet/index_ger.html
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

11
What is the hardest part of programming?
What constitutes programming?

> Understanding requirements

> Design
> Testing
> Debugging
> Developing data structures and algorithms
> User interface design
> Profiling and optimization
> Reading code
> Enforcing coding standards
> ...

13
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

14
 Three views of OO

The Scandinavian view is

that an OO system is one
whose creators realise that
programming is modelling.

The mystical view is that an OO system

is built out of objects that send messages
to each other, and computation is the
messages flying between objects.

The software engineering view is that an

OO system is one that supports data
abstraction, polymorphism by late-
binding of function calls, and inheritance.
15
This slightly tongue-in-cheek description was attributed to Ralph
Johnson by James Noble in The Myths of Object-Orientation.
ECOOP 2009.
http://dx.doi.org/10.1007/978-3-642-03013-0_29
http://scgresources.unibe.ch/Literature/P2/Nobl09a-MythsOfOO.pdf
None of these views is “wrong”, but each emphasizes different
important aspects of OOP:
• The Scandinavian view originates from Simula (1960s), a language that uses
OO concepts to simulate real world objects. Good OO design reflects this
principle as domain cncepts are directly modeled (simulated) in your code.
• The “mystical” view originates from Smalltalk (1970s), which establishes
that the model og objects passing messages offers a universal computational
model.
• The SE view (1980) expresses the realization that OOP offers a way to
master complexity of very large software systems.
Programming is modeling

16
Programs are executable models that are used to achieve some
effect in the real world. With a good design, the program code
reflects clearly the models as we want them to be.

Programming languages offer us a variety of different tools for

expressing executable models. If we pick the right tool, the job is
easier.
What is Object-Oriented Programming?

Encapsulation Abstraction & Information Hiding

Composition Nested Objects

Distribution of Separation of concerns

(e.g., HTML, CSS)
Responsibility

Message Passing Delegating responsibility

Conceptual hierarchy,
Inheritance polymorphism and reuse
17
Encapsulation means that related entities are bundled together,
for example, a Shape object encapsulates data and related
operations for shapes.
Abstraction means that we ignore irrelevant details, for example,
we abstract from the details of a Shape object and just use its
interface (i.e., its operations).
Information hiding means that we hide (forbid access to) the
representation behind an abstraction, for example, you may not
directly access the state of a Shape but must access it only
through its interface.
These three concepts are closely related, but clearly different.
Composition refers to the fact that we can compose complex
objects from simpler ones. A Picture may be composed of many
shapes.

Distribution of Responsibility means that we break complex tasks

into simpler ones, and handle them at the appropriate level of
abstraction, and close to where the relevant knowledge is. If you
need to resize a shape object, that task should be handled by the
shape itself.

Message Passing refers to the idea that you do not “apply

procedures to objects”, but that you politely ask them to do
something by sending them a message. The object itself then
decides whether it has a method to handle that message.
Inheritance is, simply seen, just a mechanism to share behaviour
and state (i.e., methods and instance variables) between a class
and its subclasses.

As we shall see, inheritance can be used in object-oriented design

for three different, but related purposes:
1. Conceptual hierarchy (a Rectangle is a Shape)
2. Polymorphism (I can use a rectangle anywhere I expect a
shape)
3. Reuse (the Rectangle class reuses everything it inherits from
Shape)

In a good object-oriented design, all three of these come together.

 Procedural versus OO designs

Problem: compute the total area of a set of geometric

shapes
public static void main(String[] args) {
Picture myPicture = new Picture();
myPicture.add(new Square(3,3,3)); // (x,y,width)
myPicture.add(new Rectangle(5,9,5,3)); // (x,y,width,height)
myPicture.add(new Circle(12,3,3)); // (x,y,radius)

System.out.println("My picture has size " + myPicture.size());

}

(10,12)

(5,9)

(6,6) How to compute the size?

(12,3)
(3,3)
18
Procedural approach: centralize computation
double size() {
double total = 0;
for (Shape shape : shapes) {
switch (shape.kind()) {
case SQUARE:
Square square = (Square) shape;
total += square.width * square.width;
break;
case RECTANGLE:
Rectangle rectangle = (Rectangle) shape;
total += rectangle.width * rectangle.height;
break;
case CIRCLE:
Circle circle = (Circle) shape;
total += java.lang.Math.PI * circle.radius * circle.radius / 2;
break;
}
}
return total;
}
19
Here we see a classical procedural design consisting of
algorithms and data structures. Squares, Rectangles and Shapes
are passive data structures, and algorithms have complete control
to manipulate them.
Object-oriented approach: distribute computation

double size() {
double total = 0;
for (Shape shape : shapes) {
total += shape.size();
}
return total; public class Square extends Shape {
} ...
public double size() {
return width*width;
}
}

What are the advantages and

disadvantages of the two solutions?
20
In the object-oriented design, the responsibility of computing the
size of a shape is distributed to the objects with the necessary
knowledge to perform the computation. The resulting design is
fundamentally different.

There are clear tradeoffs between the two approaches. Although

OO design has certain advantages, it is not “better” in absolute
terms.

Exercise: what are the tradeoffs?

Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

21
Object-Oriented Design in a Nutshell

> Identify minimal requirements

> Make the requirements testable
> Identify objects and their responsibilities
> Implement and test objects
> Refactor to simplify design
> Iterate!

22
Responsibility-Driven Design

> Objects are responsible to maintain information and

provide services

> A good design exhibits:

—high cohesion of operations and data within classes
—low coupling between classes and subsystems

> Every method should perform one, well-defined task:

—High level of abstraction — write to an interface, not an
implementation

23
Cohesion refers to the notion that related entities should be close
together. This is supported by encapsulation mechanisms, like
classes and packages. A good design is cohesive, so that when
you have to change something or add new features, then the parts
to change can be found together.

Coupling refers to the dependencies between parts of a software

system, i.e., what parts call each other, use each other, etc. High
coupling is bad because if you change something, it will affect
many other parts. A good design exhibits low coupling.
Design by Contract

> Formalize client/server contract as obligations

> Class invariant — formalize valid state
> Pre- and post-conditions on all public services
—clarifies responsibilities
—simplifies design
—simplifies debugging

24
Extreme Programming

Some key practices:

> Simple design
—Never anticipate functionality that you “might need later”
> Test-driven development
—Only implement what you test!
> Refactoring
—Aggressively simplify your design as it evolves
> Pair programming
—Improve productivity by programming in pairs

25
Testing

> Formalize requirements

> Know when you are done
> Simplify debugging
> Enable changes
> Document usage

26
Code Smells

> Duplicated code

> Long methods
> Large classes
> Public instance variables
> No comments
> Useless comments
> Unreadable code
> …

27
Refactoring

“Refactoring is the process of rewriting a computer

program or other material to improve its structure or
readability, while explicitly keeping its meaning or
behavior.”
— wikipedia.org

Common refactoring operations:

> Rename methods, variables and classes
> Redistribute responsibilities
> Factor out helper methods
> Push methods up or down the hierarchy
> Extract class
> …
28
Design Patterns

“a general repeatable solution to a commonly-occurring problem in

software design.”

Example
> Adapter — “adapts one interface for a class into one that a client
expects.”

Patterns:
> Document “best practice”
> Introduce standard vocabulary
> Ease transition to OO development
But …
> May increase flexibility at the cost of simplicity

29
We will see several design patterns during the course, but we’ll
only look in detail near the end. Most of the design patterns we
will see are described in the classic book by the “Gang of Four.”
An electronic version is available to students of this course.
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

30
Why Java?

Special characteristics
> Resembles C++ minus the complexity
> Clean integration of many features
> Dynamically loaded classes
> Large, standard class library

Simple Object Model

> “Almost everything is an object”
> No pointers
> Garbage collection
> Single inheritance; multiple subtyping
> Static and dynamic type-checking
Few innovations, but reasonably clean, simple and usable.
31
History

1950

FORTRAN
ALGOL 60 LISP
1960 COBOL

PL/1
Simula 67
ALGOL 68
1970
Pascal
Smalltalk 72 C Prolog
Clu
awk
Modula-2
1980
Smalltalk 80
C++ Ada
Eiffel Oberon
Objective C Self Perl
1990
Python
Java
JavaScript Ruby php Ada 95
Squeak
2000
C#
Groovy

Pharo 32
2010
Java adopts much of its syntax from C++, to make it appeal to
seasoned C++ programmers, but adopts many language features
from Smalltalk, such as single inheritance, implementation based
on a virtual machine, and automatic garbage collection.
Roadmap

> Goals, Schedule

> What is programming all about?
> What is Object-Oriented programming?
> Foundations of OOP
> Why Java?
> Programming tools, version control

33
Programming Tools

Know your tools!

—IDEs (Integrated Development Environment)— e.g., Eclipse

—Version control system — e.g., svn, git
—Build tools — e.g., maven, ant, make
—Testing framework — e.g., Junit
—Debuggers — e.g., jdb
—Profilers — e.g., java -prof, jip
—Documentation generation — e.g., javadoc

34
Version Control Systems

A version control system keeps track of multiple file

revisions:
> check-in and check-out of files
> logging changes (who, where, when)
> merge and comparison of versions
> retrieval of arbitrary versions
> “freezing” of versions as releases
> reduces storage space (manages sources files + multiple
“deltas”)

35
Version Control

Version control enables you to make radical changes to a

software system, with the assurance that you can
always go back to the last working version.

✎ When should you use a version control system?

✔ Use it whenever you have one available, for even the
smallest project!

Version control is as important as testing in iterative

development!

36
What you should know!

✎ What is meant by “separation of concerns”?

✎ Why do real programs change?
✎ How does object-oriented programming support
incremental development?
✎ What is a class invariant?
✎ What are coupling and cohesion?
✎ How do tests enable change?
✎ Why are long methods a bad code smell?

37
Can you answer these questions?

✎ Why does up-front design increase risk?

✎ Why do objects “send messages” instead of “calling
methods”?
✎ What are good and bad uses of inheritance?
✎ What does it mean to “violate encapsulation”?
✎ Why is strong coupling bad for system evolution?
✎ How can you transform requirements into tests?
✎ How would you eliminate duplicated code?
✎ When is the right time to refactor your code?

38
 Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)

You are free to:

Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material for any purpose, even commercially.

The licensor cannot revoke these freedoms as long as you follow the license terms.

Under the following terms:

Attribution — You must give appropriate credit, provide a link to the license, and indicate if
changes were made. You may do so in any reasonable manner, but not in any way that
suggests the licensor endorses you or your use.



ShareAlike — If you remix, transform, or build upon the material, you must distribute your
contributions under the same license as the original.

No additional restrictions — You may not apply legal terms or technological measures that legally
restrict others from doing anything the license permits.

http://creativecommons.org/licenses/by-sa/4.0/