2/10/11

Introduc.on to Object-Orienta.on
Baris Aktemur CS1003 | Ozyegin University

Whats an Object
An object packages both data and the procedures that operate on that data. An object performs an opera.on when it receives a request (or message) from a client.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

2/10/11

OO Design is hard
Many factors come into play: encapsula.on, granularity, dependency, exibility, performance, evolu.on, reusability, etc. Many dierent approaches.
Write a problem statement, single out the nouns and verbs, and create corresponding classes and opera.ons. Focus on the collabora.ons and responsibili.es in the system. Model the real world and translate the objects found during analysis into design.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

OO Design is hard
Many real-world objects, but... OO designs oYen end up with classes that have no counterparts in the real world. Strict modeling of the real world leads to a system that reects today's reali.es but not necessarily tomorrow's. The abstrac.ons that emerge during design are key to making a design exible.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
4

Low-level classes (e.g. arrays) Higher-level classes (e.g. Composite)

2/10/11

Interface
Every opera.on declared by an object species the opera.on's name, the objects it takes as parameters, and the opera.on's return value. This is known as the opera.on's signature. The set of all signatures dened by an object's opera.ons is called the interface to the object. An object's interface says nothing about its implementa.ondierent objects are free to implement requests dierently.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
5

Type
A type denotes a par.cular interface. An object is said to have the type C if it accepts all requests for the opera.ons dened in the interface named C. An object may have many types. Widely dierent objects can share a type. A type is a subtype of another if its interface contains the interface of its supertype.
A subtype inherits the interface of its supertype.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
6

2/10/11

Encapsula.on
Requests are the only way to get an object to execute an opera.on. Opera.ons are the only way to change an object's internal data. Because of these restric.ons, the object's internal state is said to be encapsulated
it cannot be accessed directly its representa.on is invisible from outside the object.

Objects are known only through their interfaces.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
7

Dynamic Binding
When a request is sent to an object, the par.cular opera.on that's performed depends on both the request and the receiving object. Dierent objects that support iden.cal requests may have dierent implementa.ons. The run-.me associa.on of a request to an object and one of its opera.ons is known as dynamic binding. (or dynamic dispatch)
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
8

2/10/11

Polymorphism
Issuing a request doesn't commit you to a par.cular implementa.on un.l run.me. Polymorphism: being able to subs.tute objects that have iden.cal interfaces for each other at run-.me. Simplies the deni.ons of clients Decouples objects from each other Lets objects vary their rela.onships to each other at run-.me.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
9

Polymorphism
From Design Paherns Explained by Shalloway and Troh: Polymorphism: Being able to refer to dierent deriva.ons of a class in the same way, but gejng the behavior appropriate to the derived class being referred to.

10

2/10/11

Object Implementa.on
A class denes the objects
internal data representa.on opera.ons

An object is an instance of a class.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

11

Subclassing
Inheritance:
Subclass inherits all the deni.ons (data and opera.ons) of the superclass. (mod. visibility)

Subclasses can rene and redene behaviors of their parent classes.

A class may override an opera.on dened by its parent class. Overriding gives subclasses a chance to handle requests instead of their parent classes.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
12

2/10/11

Abstract Class
An abstract class denes a common interface for its subclasses. Defers some or all of its implementa.on to opera.ons dened in subclasses
abstract opera9ons

Cannot be instan.ated. Classes that aren't abstract are called concrete classes.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
13

Abstract Class

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

14

2/10/11

Mixin Class
A mixin class is a class that's intended to provide an op:onal interface or func.onality to other classes.
Similar to an abstract class: not intended to be instan.ated.

Mixin classes require mul.ple inheritance

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

15

Class vs. Interface Inheritance

Class is implementa.on Type is interface An object can have many types, but only one class. Objects of dierent classes can have the same type. However, a class also denes a type.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

16

2/10/11

Class vs. Interface Inheritance

Class inheritance denes an object's implementa.on in terms of another object's implementa.on.
a mechanism for code and representa.on sharing.

Interface inheritance (or subtyping) describes when an object can be used in place of another.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

17

Class vs. Interface Inheritance

Dis.nc.on in C++ is not explicit
inheritance means both interface and implementa.on inheritance.

Pure interface inheritance in C++

inherit publicly from pure abstract classes.

Pure implementa.on or class inheritance

private inheritance.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

18

2/10/11

Class vs. Interface Inheritance

Class inheritance is for implementa.on reuse Interface inheritance is important:
polymorphism depends on it

Ideally a subclass should add or override opera.ons and should not hide opera.ons of the parent class.
All subclasses become subtypes of the abstract class, sharing the same interface
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
19

Program to an Interface, not an Implementa.on

Two benets
Clients remain unaware of the specic types of objects they use, as long as the objects adhere to the interface that clients expect. Clients remain unaware of the classes that implement these objects.

Greatly reduce implementa.on dependence

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

20

10

2/10/11

Program to an Interface, not an Implementa.on

Don't declare variables to be instances of par.cular concrete classes. Commit only to an interface dened by an abstract class. Use crea.onal paherns
Abstract out object crea.on Associate an interface with its implementa.on transparently
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
21

Reuse Mechanisms
(Class) Inheritance
White-box reuse

Composi.on
Black-box reuse Must have well-dened interfaces

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

22

11

2/10/11

Class inheritance
+ Straighmorward + Easy to modify the implementa.on being reused Cant change the implementa.on dynamically breaks encapsula.on: superclass is exposed to subclass; changing superclass likely to force a change in subclasses

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

23

Composi.on
+ Strong encapsula.on + Easily change the implementa.on at run.me + Fewer implementa.on dependencies + Keep class hierarchies manageably small Design interfaces very carefully Many more objects and rela.ons

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

24

12

2/10/11

Favor Composi.on over Inheritance

25

Delega.on
Achieving inheritance reuse via composi.on A receiving object delegates opera.ons to its delegate. Receiver passes itself to the delegate
similar to referring to the receiver object using this in inheritance

Delega.on is a good design choice only when it simplies more than it complicates.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
26

13

2/10/11

Delega.on

Can change rect to circle at run.me to make the window circular.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
27

Associa.on
An associa9on is a rela.onship between two classes that allows instances created from those classes to send messages to each other.

[Robert Mar.n, Agile Principles, Pa6erns and Prac:ces in C#, Pren.ce Hall, 2006 ]

28

14

2/10/11

Associa.on
The navigability of the associa.on can be restricted by adding arrowheads to the associa.ons. When an arrowhead is present, the associa.on can only be navigated in the direc.on of the arrow. This means that the class to which the arrow points does not know about its associate.

[Robert Mar.n, Agile Principles, Pa6erns and Prac:ces in C#, Pren.ce Hall, 2006 ]

29

Aggrega.on
An aggrega9on is a special form of associa.on. Aggrega.on implies a whole/part rela.onship. The class adjacent to the white diamond is the whole, and the other class is its part. The whole/part rela.onship is purely connota.ve; there is no seman.c dierence from associa.on.

[Robert Mar.n, Agile Principles, Pa6erns and Prac:ces in C#, Pren.ce Hall, 2006 ]

30

15

2/10/11

Composi.on
Composi9on is a special form of associa.on. It implies that the whole is responsible for the life.me of its part. This responsibility does not imply either crea.on or dele.on responsibility. Rather it implies that the whole must see to it that the part is somehow deleted.

[Robert Mar.n, Agile Principles, Pa6erns and Prac:ces in C#, Pren.ce Hall, 2006 ]

31

Caveat
In GOF, composi.on is called aggrega.on, and aggrega.on is called composi.on.
A mo.va.on for why UML was needed

32

16

2/10/11

Design for Change

An.cipate new requirements and changes to exis.ng requirements Design for evolu.on Inexible design risks major redesign in the future
Unan.cipated changes are expensive

Each design pahern ensures that a system can change in some specic ways.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
33

Common Causes of Redesign

Crea.ng an object by specifying a class explicitly
create objects indirectly.

Dependence on specic opera.ons.

avoid hard-coded requests

Dependence on hardware and soYware plamorm.

abstract out dependences
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
34

17

2/10/11

Common Causes of Redesign

Dependence on object representa.ons or implementa.ons.
hide how an object is represented, stored, located, or implemented

Algorithmic dependencies.
make algorithm interchangeable

Tight coupling
use techniques such as abstract coupling and layering to promote loosely coupled systems.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
35

Common Causes of Redesign

Extending func.onality by subclassing.
Favor composi.on over inheritance.

Inability to alter classes conveniently.

Use delega.on to redirect the target.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

36

18

2/10/11

Frameworks
A set of coopera.ng classes that make up a reusable design for a specic class of soYware
ar.s.c drawing, music composi.on, and mechanical CAD, nancial modeling

Customize a framework to a par.cular applica.on by crea.ng applica.on-specic subclasses of abstract classes from the framework.
[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]
37

Frameworks
A framework is a par.ally complete soYware (sub)system that is intended to be instan.ated. It denes the architecture for a family of (sub) systems. It also denes the places where adapta.ons for specic func.onality should be made. In an OO environment, a framework consists of abstract and concrete classes.
[Buschmann et al., POSA]
38

19

2/10/11

Frameworks
Framework dictates the architecture of the applica.on Applica.on designer concentrates on the specics of the applica.on. Frameworks emphasize design reuse over code reuse

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

39

Inversion of Control
Library:
You write the main method and call the library

Framework:
You reuse the main body and write the code it calls.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

40

20

2/10/11

Hollywood Principle
Dont call us, we will call you. AKA Greyhound Principle:
Leave the driving to us

Implement the interfaces, get registered, get called when the .me is right. Framework determines the ow of control.

h6p://en.wikipedia.org/wiki/Hollywood_Principle

41

Frameworks
Very valuable, but hard to design A change in the framework interface aects all the derived applica.ons Steep learning curve
Documen.ng using design paherns may make the learning process easier

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

42

21

2/10/11

Frameworks vs. Design Paherns

Design paherns are more abstract than frameworks Design paherns are smaller architectural elements than frameworks. Design paherns are less specialized than frameworks.

[Gamma, Helm, Johnson, and Vlissides. Design Pa6erns. Addison-Wesley, 1994]

43

Law of Demeter
Governs the communica.on structure within an object-oriented design
restricts message-sending statements in method implementa.ons only talk to your immediate friends

Message target can only be one of the following objects:

the method's object itself (C++: this) an object that is an argument in the method's signature an object referred to by the object's ahribute an object created by the method an object referred to by a global variable
h6p://c2.com/cgi/wiki?LawOfDemeter
44

22

2/10/11

Enabling Techniques for SoYware Architecture

Abstrac.on
The essen.al characteris.cs of an object that dis.nguish it from all other kinds of objects and thus provide crisply dened conceptual boundaries rela.ve to the perspec.ve of the viewer.

[POSA]

45

Enabling Techniques for SoYware Architecture

Encapsula.on
Group the elements of an abstrac.on that cons.tute its structure and behavior

Informa.on hiding
Conceal the details of a components implementa.on from its clients.

Modulariza.on
Meaningful decomposi.on of a system into subsystems Physical packaging of logical structure
[POSA]
46

23

2/10/11

Enabling Techniques for SoYware Architecture

Separa.on of concerns
Dierent and unrelated responsibili.es should be separated from each other within a soYware system

Coupling
Strength of associa.on established by a connec.on from one module to another

Cohesion
Degree of connec.vity between the func.ons and elements of a single module.
[POSA]
47

Enabling Techniques for SoYware Architecture

Separa.on of interface and implementa.on Single point of reference
Avoid problems of inconsistency C++: single point of deni.on but several points of declara.on

[POSA]

48

24