A Seminar on Encapsulationhttp://www.cs.tau.ac.il/~msagiv/courses/encapsulate.html

Mooly Sagiv

Schriber 317

msagiv@post

Office Hours Wed. 14-15

Noam Rinetzky

Outline

1. General information

2. Seminar subject

3. How to give a presentation

General Information

• Prerequisites– Compilers | Program Analysis| Program Verification|

Semantics| Principles of OO

• Requirements– Select a topic (Monday 7/11)

– Read introductory material

– Participate in 10 seminar talks (2 lectures)

– Present a paper

Tentative Schedule

• November 3: Intro

• November 10: Separation Logic

• Student lectures

• February 2: Summary

What is encapsulation?

Common Answer(1) Encapsulation is the ability of an object to place a boundary around its properties (ie. data) and methods (ie. operations)

Programs written in older languages suffered from side effects where variables sometimes had their contents changed or reused in unexpected ways. Some older languages even allowed branching into procedures from external points

This led to 'spaghetti' code that was difficult to unravel, understand and maintain

Encapsulation is one of three basic principles within object oriented programming languages

Common Answer(2) Object variables can be hidden completely from external access

These private variables can only be seen or modified by use of object accessor and mutator methods

Access to other object variables can be allowed but with tight control on how it is done

Methods can also be completely hidden from external use

Those that are made visible externally can only be called by using the object's front door (ie. there is no 'goto' branching concept).

Is it that simple?

Does private guarantee encapsulation?

Encapsulation by Exampleclass Square {

int len;

Square(int l) {

assert(0 < l);

len = l;

}

int circumference() {

return 4*len;

}

}

main() {

Square sq = new Square(2);

assert( 0< sq.circumference());

}

main() {

Square sq = new Square(2);

sq.len = -2;

assert( 0 < sq.circumference());

}

OK

oops

Importance of Encapsulation (Information Hiding)

class Square {

private int len;

Square(int l) {

assert(0<l);

len = l;

}

int circumference() {

return 4*len;

}

}

main() {

Square sq = new Square(2);

assert( 0< sq.circumference());

}

main() {

Square sq = new Square(2);

sq.len = -2;

assert( 0 < sq.circumference());

}

OK

Oh, no!

Importance of Encapsulation (Information Hiding: Restricted Mutations)

class Square {private int len; Square(int l) { assert(0 < l); len = l;}int circumference() { return 4*len;}set(int l) { assert(0<l); len = l;}}

main() { Square sq = new Square(2); assert( 0< sq.circumference()); }

main() {Square sq = new Square(2);

sq.set(3); assert( 0 < sq.circumference()); }

main() {Square sq = new Square(2);

sq.set(-3); assert( 0 < sq.circumference()); }

OK

OK

Oh, no!

Importance of Encapsulation (Representation Independence)

class Square {private int circu; Square(int l) { assert(0 < l); circu = 4 * l;}int circumference() { return circu;}int setLen(int l) { assert( 0 < l); circu = l*4;}Int len() { return circu / 4;}}

main() {Square sq = new Square(2);

assert(0 < sq.circumference()); }

main() {Square sq = new Square(2);

assert(0 < sq.len()); }

OK

OK

Encapsulation of objects

Example: class frame• A Frame is comprised

of two squares– An outer square

– An inner square

Encapsulation of (sub)objects

class Frame {

private Square outer, inner;

Frame(Square i, Square o) {

assert(i.len() <o.len());

outer = o;

inner = i;

}

int size() {

return outer.len() * outer.len() –

inner.len() * inner.len();

}

Main() {

Square small = new Square(1);

Square big = new Square(3);

Frame frm = new Frame(small, big);

assert(0 < frm.size());

small.setLen(5);

assert(0 < frm.size());

}

OK

oops

Deep heapsClass IntList { int size; IntElem h;

List() { this.size = 0; this.h = null; }

void insert(IntElem e) {this.size ++;

if (this.h == null) this.h = e;

else this.h.add(e); }}

Class IntElem { int data; IntElem n;

IntElem(int d) { this.data = d;

}

void add(IntElem e) { if (this.n == null)

this.n = e; else this.n.add(e); }}

Deep heapsmain() {

List x = new List();

List y = new List();

IntElem x1 = new IntElem(1);

x.add(x1);

IntElem y1 = new IntElem(2);

y.add(y1);

IntElem z = new IntElem(3)

x.add(z);

y.add(z);

IntElem w = new IntElem(4);

y.add(w);

n

n

h

h

y

size=0

x

size=0size=1

size=1

size=2

n

3

z

4

w1

x1

2

y1size=2size=3

Modification via Iteratorsclass List { Elem h; List() { this.h = null; } void add (Object d) {

Elem e = new Elem(d); if (this.h == null)

this.h = elem; else this.h.add(d); } Iterator iterator() { return new Iterator(this); } }

class Elem { Object o; Elem n;…}

Class Iterator { List c; Elem e; Iterator(List lst) {

this.c = lst; this.e = lst.h; }}

Modification via IteratorsMain() {

List list = new List();

list.add(new Square(1));

list.add(new Square(2));

list.add(new Square(3));

Iterator itr1 = list.iterator();

Iterator itr2 = list.iterator();

itr1.remove();

Square s = (Square) itr2.next();

}

2

n

o

3

n

o

itr1

c

e

itr2

ce

list

1

o

h

Modification via IteratorsMain() {

List list = new List();

list.add(new Square(1));

list.add(new Square(2));

list.add(new Square(3));

Iterator itr1 = list.iterator();

Iterator itr2 = list.iterator();

itr1.remove();

Square s = (Square) itr2.next();

}

list

1

o

3

n

o

itr2 itr1

n

cc

ee

h2

n

o

h

Encapsulation Goals

• Develop a programming language• Expressive and convenient• Allow modular reasoning• “Controlled” side-effects • Allow library updates

– Representation independence• Secure• Easier program optimization• Easier concurrent programming

Is it possible?

Semantic properties

Modular Assume/Guarantee

ReasoningClass

Specification

Verifier

1. Correct API usage

2. Correct implementation

Idea 1: Ownership

• Define a binary relation on objects– a owns b

• Only methods of the owner can access fields

• Ownership can be enforced by a type system

• Restricts programming model• Restricts aliasing/sharing

Ownership (Clarke & Drossopoulo)

class List <owner, data> {

Link <this,data> head;

void add(Data <data> d) writes under(this) {

head = new Link<this, data>(d, head);

}

}

class Main <> {

List<this, world> list;

Main() writes this {

list = new List<this, world>; }

void populate() writes under (this.1) {

list add(new Data<world>);

list.add(new Data<world>);}

static void main() writes under world {

Main main = new Main<>;

main.populate();

Object GraphWorld

Data Data

List

Link Link

Main

Reasoning about programs using ownership

List<p,world> list1;List<q,world> list2;

for (i = 0; i < 10; i++) { list1.add(new Data<world>(i)); // exp1 } for (i = 0; i < 10; i++) { list2.add(new Data<world>(i)); // exp2

Questions:

• Are list1 and list2 aliases?

•Do exp1 and exp2 interfere?

•Can the loops be fused?

Other concepts

• Other ownership models– SPEC C#

• Object oriented effect system– Based on uniquness

• Alias types

• Islands

• Separation logic (next week)

Summary

• Everybody agrees that encapsulation is desired

• But no agreement on the exact definition

Related Issues

• Sharing

• Aliasing

• Class (object) invariant

• Modularity

• Confinment

Giving a presentation

Ian Parbery

How to give a presentation

• What to say and how to say it

• Getting through the audience

• Visual aids

What to say and how to say it

• Communicate the Key Ideas• Don’t get bogged down in Details

– The best talk make you read the paper

• Structure your talk• Use Top-Down approach

– Introduction– Body– [Technicalities]– The Conclusion

Use Examples

Introduction

• Define the problem

• Motivate the audience

• Introduce terminology

• Discuss earlier work

• Emphasize the contributions

• [Provide a road map]

Use Examples

The body

• Abstract the major results

• Explain the significance of the results

• Explain the main techniques

• Use enlightening examples

• Demonstrations are welcome

[Technicalities]

• Expert only part

• Show something really interesting beyond the paper/tool

The Conclusion

• Hindsight is clearer than Foresight

• Give open problems/further work

• Indicate that your talk is over

Know your audience

• Background

Getting through the Audience

• Use Repetitions

• Remind, don’t assume

• Don’t over-run

• Maintain Eye Contact

• Control your voice

• Control your motion

• Take care of your appearance

Visual Aids

• PowerPoint transparencies

• Don’t overload transparencies

• Don’t use too many transparencies

• Use Overlays Properly

• Use Color Effectively

• Use Pictures and Tables

• The blackboard can be used too

Don’t overload transparencies

• The input of the program can be arbitrary.

• Let x be a prime number, i.e., all the numbers z<x do not divide x. y be the next prime number, i.e., etc.

• Arbitrary input• Prime number x

– The next prime y

Use overlays (im)properly

• Item 1– Item 1.1– Item 1.2

• Item 2– Item 2.1

• Item 2.1.1

Use colors properly

• Item 1

• Item 2

• Item 3

http://www.cs.tau.ac.il/~msagiv/courses/encapsulate.html