The Object Oriented Paradigm in perspective

The Object Oriented Paradigm in perspec2ve :

From Plato and Aristotle to Alan Kay.. and beyond

Ruben Gonzalez Blanco Nov 2013

Modeling and Understanding the World

Philosopher Computer Scien2st

The School of Athens (by Raphael)

Ideas

Things

Plato Aristotle

The Theory of Ideas from Plato

Sensi4ve World

Intelligible World

Horse Idea

Mammal Idea

Instan4a4on

First are the Ideas, then the Things

Most of our OOP soPware is “Platonic”

CLASS

Object1 Object2 Object3

Create Object

INTERFACE

Run4me World

Design&Coding World

First the Code, then the Objects

Interface Shape { draw(Canvas c); move(int x, int y); }

class Circle implements Shape { // a:ributes int cx; int cy; int radius; // implementa>on draw(Canvas c) { c.drawEllipse(cx,cy, r); } move(int x, int y) { cx = cx+x; cy =cy+y } setC(int x, int y) { cx=x; cy=y; } setR(int radious) { r=radious; } }

Main() { Circle s1 = new Circle(); s1.setC(100,50) s1.setR(20); Canvas c = new DefaultCanvas(); c.addShape(s1); // registered as Shape c.show(); }

��$��

��

a"rributes*

memory&

'�

'�

'�

��$��!�� #� ��#��

draw()*implementa3on*

�%� ��&�

��

��#��

�!��!��

�!��" ��

��

��

opera3ons*table*

'�

��"��

Design& Coding World Run4me World

The Forms Theory from Aristotle Only 1 World = Sensi4ve World

Concepts or Forms = Abstrac4ons

Horse Form

Mammal Form

Abstrac4on

(extract the general from the par2cular)

(in our minds)

First are the Things, then the Forms

The Forms are not separated from the Things

Horse Form

Horse Form Horse

Form

Form Theory from Aristotle

Substance

Form Physical Ma`er

Accidents

(Thing)

(Idea)

(thing proper4es varia4ons)

•  Forms can have different levels of abstrac2ons •  Ma`er can disappear, Forms persist

OOP and Form Theory

Substance

Form Physical Ma`er

Accidents

(Thing)

(Idea)

Object

Class “Electronic” Ma`er (Object in the Computer Memory, processed

by the CPU)

State (Object aKributes=status varia4ons)

Interface

(thing proper4es varia4ons)

code

code

(Abstrac4on) (Abstrac4on)

(Abstrac4on)

Sensible World Run4me World

“Aristotelic” view of OOP: What it really ma`ers are the Objects

Interface Shape {

draw(Canvas c);

move(int x, int y);

}

class Circle implements Shape {

// a$ributes

int cx;

int cy;

int radius;

// implementa0on

draw(Canvas c) {

c.drawEllipse(cx,cy, r);

}

move(int x, int y) {

cx = cx+x;

cy =cy+y

}

setC(int x, int y) {

cx=x;

cy=y;

}

setR(int radious) {

r=radious;

}

}

draw()

move()

_Line_draw()

_Line_move()

X1=100

Y1=100

X2=100

Y2=200

draw()

move()

_Circle_draw()

_Circle_move()

Cx=80

Cy=90

R=50

show()

addShape()

removeShape()

_DefaultCanvas_show()

…

shapes=[s1]

c1:DefaultCanvas

onMousePressed()

onMouseMoved()

onMouseReleased()

_CircleTool_onMouseReleased()

…

canvas=c1

..

:CircleTool

draw()

move()

_Circle_draw()

_Circle_move()

Cx=80

Cy=90

R=50

draw()

move()

_Circle_draw()

_Circle_move()

Cx=80

Cy=90

R=50

onMouseReleased(MouseEvent mevent) {

//..get radious from mevent posi3on

r = ….

Circle circle = new Circle();

circle.setC(x,y);

circle.setR(r);

// registered as Shape

canvas.addShape(circle);

}

App=Run4me World Design & Coding World

The OOP concept revisited 40 years later

Dr. Alan Kay

OOP by Alan Kay

"OOP to me means only messaging, local reten4on and protec4on and hiding of state-‐process, and extreme late-‐binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." -‐ Dr. Alan Kay

Objects in OOP are “like” Cells

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -‐-‐ it took a while to see how to do messaging in a programming language efficiently enough to be useful).

h`p://www.purl.org/stefan_ram/pub/doc_kay_oop_en

A “primi2ve” form of object

h`p://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Abstract.html

Dr. Alan Kay OOP realiza2on : Smalltalk Smalltalk is a founda2onal programming language that is based on pervasive message passing, pervasive dynamic and strong typing, pervasive reflec4on and pervasive object orienta4on.

h`p://www.smalltalk.org/ar2cles/ar2cle_20100320_a3_Gekng_The_Message.html

Smalltalk is one of the first object-‐oriented programming languages. Its design was influenced by Lisp, Logo, Sketchpad, Flex and Simula. Smalltalk was developed as a research project at Xerox PARC in the 1970s by a team whose members included Dr. Alan Kay, Dan Ingalls, Adele Goldberg, Ted Kaehler, [Dianna Merry-‐Shipiro], Sco` Wallace and others.

Understanding OOP

An Object is a run4me en4ty that processes messages using dynamic binding

Message

Dynamic Binding = Late Binding

Binding mechanism

Message

Object

Message processor Implementa2on

Data A`ributes=State

Opera2ons Realiza2on

A`ributes Interface Opera2ons Specifica2on

Class

Data

Dynamic Binding

Message

At run-‐2me 1

Dynamic Binding

Message

Binding mechanism

At run-‐2me 1

2

Dynamic Binding

Message

Binding mechanism

Binding mechanism



Data

At run-‐2me 1

2

3


Binding mechanism



Data

Not Bound 1


Binding mechanism



Data

Binding mechanism



Data

Message

Not Bound

Linked when the message is received

1

2

•  Implementa2on is bound in the last moment •  (when a message is received)

The same object can change its implementa2on between messages recep2on

Binding mechanism

Object2



Data

Object1

1

The same object can change its implementa2on between messages recep2on

Binding mechanism

Object2



Data

Binding mechanism

Object2



Data

Object1

Object1

1

2

An object can interact with different Implementa2ons of the same interface

Binding mechanism

Object2



Binding mechanism

Object3



Data

Data

Object1

•  Same “Interface” and different implementa2on •  Implementa2on can vary at run2me •  Flexibility = easily recombine exis2ng objects into new configura2ons •  Extensibility = easily add new behaviours

Polymorphism and Encapsula2on

Binding mechanism



Data

INTERFACE (specifica2on)

Mul2ple muta2ons of the same “Thing” Same object instance with varia2ons in its implementa2on Same specifica2on (interface) with different instances realiza2ons

IMPLEMENTATION1 (realiza2on)

Binding mechanism



Data

IMPLEMENTATION2 (realiza2on)

Hidden

The “P” in OOP is misleading

OOP is a Computa4onal Model Not a Programming Model

Can be implemented in different programming languages

An object is like a “virtual” server

OOP should be equals to Object Oriented Processing

Most of the “modern” so called OO languages (C++, Java, …) are more focused on the Programming part than the Computa2onal part (the run2me objects)

Interface Class Inheritance

Messages Object Late Binding

Design & Coding Time Run4me Processing

Plato Aristotle

How SoPware Objects Would be like in our physical World?

( just for adding clarifica>on )

How SoPware Objects Would be like in our physical World? The Post-‐World

a PostBox Object

The Post-‐World

aPostboxObject

Ann

aPostBoxObject

Teacher Postbox (abstract or representa>on box)

slot Interface

How it is seen by other postBoxObjects (only the interface is seen, not the implementa>on)

As a Teacher implementa>on

Abstract Form

slot

teachLesson

Dynamic binding

Teacher

Student

Robert

Marie

Student Ann Dynamic binding

Teacher

Student

Robert

Marie

Student Robert Dynamic binding

Teacher

Student

Robert

Marie

Student aTapeRecorder

Dynamic binding

A C++,Java like “Typed” Post-‐World would be also possible, but would be “less” OO (less polymorphic) and more complicated to deal with

Teacher

answerQues2on

teachLesson

Teacher

aTapeRecorder exposed/referenced as a Teacher

TapeRecorderTeacher

teachLesson

answerQues2on

play

stop

forward

rewind

aTapeRecorder exposed/referenced as TapeRecoderTeacher

teachLesson

answerQues2on

play

stop

forward

rewind

concrete slots are hidden Referenced as Teacher

Teacher

•  Type=“slots Interface” is hardcoded. •  Different slots are presented in different situa2ons (type cas2ng) •  To be “more” OO polymorphic, objects always try to present themselves as the most abstract type possible

Analysis of the OOP idea and how we have implemented it during the past 40 years

Dynamic Binding is present in many places

•  func2on pointers in C and C++

•  DLLs and Shared Objects

•  “CGI” like mechanism in HTTP servers

•  GUIs

…

For origins of dynamic binding: “Fundamental Concepts in Programming Languages”. CHRISTOPHER STRACHEY -‐ 1967

Dynamic Binding is present in many places a basic example in C

typedef int (*foo)(int i);!

int fooImp1(int i ) {! return 2*i;!}!!int fooImp2(int i ) {! return i/2;!}!!void doFoo(int i,foo afoo) {!! int r = afoo(i);!! printf (“result=%d\n”,r);!

!!}!!int main (int argc, char** argv){!! foo myfoo = &fooImp1;! ! doFoo (4, myfoo); !}!

//foo is polymorphic

2A10F

memory

…

…

…

_fooImp2(int i)

fooImp2() implementa2on

…

afoo 1A001

1A001 _fooImp1(int i)

fooImp1() implementa2on

i 4

//sets the concrete “instance”

OOP applica2ons are executed as a set of collabora2ng objects

:User

object

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

DrawingTool+

Selec/onTool+

Rectangle+

Line+

Circle+

Canvas+

The so typical OOP Applica2on example…

Anatomy of an object in C, C++, Java…

draw() move()

_Circle_draw() _Circle_move()

cx=100 cy=50 r=0

s1:Shape

s1:Circle

Opera>ons specifica>on

Opera>ons realiza>on

a:ributes

draw() move()

s1:Shape

How it is seen by other objects

s1 referenced as a Shape

Dynamic Binding

s1 is a Circle class instance that implements the Shape interface

Anatomy of an object in C, C++, Java…

draw() move()

_Circle_draw() _Circle_move()

…

cx=100 cy=50 r=20

s1:Shape

s1:Circle Dynamic binding

Interface

Implementa>on

data

Opera>ons specifica>on

Opera>ons realiza>on

a:ributes

Interface Shape { draw(Canvas c); move(int x, int y); }

class Circle implements Shape { // a:ributes int cx; int cy; int radius; // implementa>on draw(Canvas c) { c.drawEllipse(cx,cy, r); } move(int x, int y) { cx = cx+x; cy =cy+y } setC(int x, int y) { cx=x; cy=y; } setR(int radious) { r=radious; } }

s1 Instan>a>on (new)

Main() { Circle s1 = new Circle(); s1.setC(100,50) s1.setR(20); Canvas c = new DefaultCanvas(); c.addShape(s1); // registered as Shape c.show(); }

Object s1 shown as “Shape” interface while its implementa>on is class “Circle”

Instan&a&on Code

Defini&on Code

A basic implementa2on in C (not C++)

��$��

��

a"rributes*

Shape*

��

��

memory&

'�

'�

'�

��$��!�� #� ��#��

draw()*implementa5on*

�%� ��&�

��

��#��

�!��!��

�!��" ��

��

��

opera5ons*table*

'�

typedef struct tShape Shape;!typedef struct tCanvas Canvas;!!// SHAPE INTERFACE DECLARATION!struct tShape {! void (*draw) (Shape * this, Canvas * canvas);! void (*move) (Shape * this , int x, int y);!

!!};!!!// CIRCLE CLASS DECLARATION!!typedef struct tCircle Circle;!!struct tCircle {! void (*draw) (Circle * this, Canvas * canvas);! void (*move) (Circle * this, int x, int y);! ! double (*circunference) (Circle * this );!

!! int cx;! int cy;! int r;!!};!!// CIRCLE CLASS OPERATIONS!!void _Circle_draw(Circle * this, Canvas* canvas) {! // code for drawing a circle!}!!double _Circle_circunference(Circle * this) {! return 2*M_PI*this->r;!}!!// code for allocating a Circle in memory!!Circle * newCircle (int cx, int cy, int r) {! Circle * circle = malloc(sizeof(Circle));! ! circle->cx = cx;! circle->cy = cy;! circle-> r= r;!! // filling function pointer members!! circle->draw = &_Circle_draw;! circle->move = &_Circle_move;! circle->circunference = &_Circle_circunference;!! return circle;! !}!

��"��

Shape**shape*Circle**shape*

draw()'move()'

_Circle_draw()'_Circle_move()'

…'

cx=100'cy=50'r=20'

s1:Shape'

s1:Circle'

show()'

s1,s2'referenced'as'a'Shape.'Implementa9on'is'bound'dynamically'at'run9me.''Line'and'Circle'implementa9on'is'not'known'by'Canvas'object'

show()'

_DefaultCanvas_show()'…'

shapes=[s1,s2]'

c1:DefaultCanvas'

GUI'OS'

c1:Canvas'

draw()'

draw()'move()'

_Line_draw()'_Line_move()'

…'

x0=0'y0=0'x1=20'y1=20'

s2:Shape'

s2:Line'

draw()'

Dynamic'binding'

Dynamic'binding'

Dynamic'binding'

class%DefaultCanvas()'{'''''''Shape[]'shapes;'''''''addShape(Shape's)'{'''''''''shapes.add(s);'''''}'''''show(){''''''''for's'in'shapes'{'''''''''''''s.draw(this);''''''''}''''}'}'

Dynamic binding in ac2on

Fine…But….

Messages are synchronous (like “func2on calls”) Classes are defined at coding 2me, can not be changed at run2me. Too much focus on coding the Hierarchies (aaarg..) No Reflec2on (yes in Java) Late binding limited to message processing

In Java, C++ like languages , inheritance is a coding mechanism, for reusing both specifica2on (interface) and realiza2on (implementa2on)

Making OOP “survive” in C++,Java like languages

Basic Advise for java,c++ like programmers

•  Programing to an interface not an Implementa4on

•  Composi4on and Delega4on over inheritance

Basic Advise for java,c++ like programmers I

Interface!!Shape!{!!!!!!!!draw(Canvas!c);!!!!!!!!move(int!x,!int!y);!}!

class!Circle!implements!Shape!{!!!!!!//!a$ributes!!!!!!!int!cx;!!!!!!!int!cy;!!!!!!!int!radius;!!!!!!!!!!!!!!!!!!//!implementa0on!!!!!!!draw(Canvas!c)!{!!!!!!!!!!!!!!c.drawEllipse(cx,cy,!r);!!!!!!!}!!!!!!!move(int!x,!int!y)!{!!!!!!!!!!!!!!cx!=!cx+x;!!!!!!!!!!!!!!cy!=cy+y!!!!!!!}!!!!!!!setC(int!x,!int!y)!{!!!!!!!!!!!!!!!cx=x;!!!!!!!!!!!!!!!cy=y;!!!!!!!}!!!!!!!setR(int!radious)!{!!!!!!!!!!!!!!!r=radious;!!!!!}!}!

draw()!move()!setC()!setR()!

_Circle_draw()!_Circle_move()!_Circle_setC()!_Circle_setR()!

cx=100!cy=50!r=20!

s1:Circle!

Shape!instanceShape()!{!!!!!Circle!s1!=!new!Circle();!!!!!s1.setC(100,50)!!!!!s1.setR(20);!!!!!return!s1;!}!

draw()!move()!setC()!setR()!

_Circle_draw()!_Circle_move()!_Circle_setC()!_Circle_setR()!

cx=100!cy=50!r=20!

s1:Shape!

draw()!move()!

s1:Shape!dra

w()!

How!it!is!seen!by!other!objects!

s1!referenced!as!a!Shape!s1!referenced!as!a!Circle!

Instan0a0on!

Object!allocated!and!running!in!memory!Programmed!code!

Reference an Object (class Circle) as its most abstract form possible (Shape)

Basic Advise for java,c++ like programmers II •  new operator is hardcode

–  Instan2a2on should be encapsulated and done via scrip2ng or declara2ve like mechanisms (xml, proper2es file, json…)

•  Never instan2ate a concrete object from other object methods –  (inject dependencies via abstract refs)

class CircleDrawingTool extends DrawingTool { DefaultCanvas canvas; CircleDrawingTool(){ this.canvas = new DefaultCanvas(); } …. }

class CircleDrawingTool extends DrawingTool { Canvas canvas; CircleDrawingTool(Canvas c){ this.canvas = c; } …. }

void instantiation (File configurationFile) { Configuration cfg = parse(configurationFile); Canvas canvas; CircleDrawingTool ctool; if (cfg.property(“canvas.type”)== DEFAULT_CANVAS) { Canvas = new DefaultCanvas(); //… set canvas attributes } // canvas injected through constructor ctool = new CircleDrawingTool(canvas) … }

Or se:er injec>on

Basic Advise for java,c++ like programmers III

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

collabora2on alloca2on

op1()

op2()

op3()

…

_class_Imp_op1()

_class_Imp_op2()

…

a11=v1

a12=v2

…

:Imp

concrete object referenced through abstract forms

Circle Shape

Shape

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

CircleDrawingTool

Canvas

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

Canvas

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

op1()

op2()

…

_class_Imp_op1()

_class_Imp_op2()

…

a01=v1

a02=v2

…

:Imp

CircleDrawingTool

dependency injec2on

Shape

new

addShape

show

draw

draw

Clearly Separate object Alloca4on and Set up (aKributes, rela4onships) from objects Collabora4on (message passing)

Instan4a4on Execu4on

Basic Advise for java,c++ like programmers IV

•  A switch-‐case by type (if object instanceof ) it is a symptom of bad polymorphic interface-‐class design

void handle(Shape* shape) { if (shape instanceof Circle) { Circle c = (Circle) shape; // handling a circle } else if (shape instanceof Line) { Line l = (Line) shape; // handling a line } else if … }

void handle(Shape* shape) { shape->doHandle(); }

Or more sophis2cated pa`ern (i.e Visitor, Chain of Reponsabili2es)

Basic Advise for java,c++ like programmers V Use Design PaKerns

–  Help you to have polymorphic designs (Composite, Builder, Prototype, Visitor, Chain of Responsibili2es, Decorator, Observer….)

•  Composi4on and Delega4on over inheritance: –  Favor extending the behavior of an object by delega2ng its message processing to a

collabora2ng object that are part of it (they compose it)

•  Programing to an interface not an Implementa4on: –  Make the applica2on work through a set of objects that collaborate between them

through interfaces or abstrac2ons that hide the concrete implementa2ons or concrete classes.

h`p://www.amazon.com/Design-‐Paèrns-‐Elements-‐Reusable-‐Object-‐Oriented/dp/0201633612/ref=sr_1_1?s=books&ie=UTF8&qid=1383378933&sr=1-‐1&keywords=design+paèrns

h`p://en.wikipedia.org/wiki/Design_Paèrns

Gang of Four

Ward Cunningham

Basic Advise for java,c++ like programmers VI Follow SOLID principles in your Design

•  Single Responsibility Principle –  A class should have one, and only one, reason to change

•  Open Closed Principle –  You should be able to extend a classes behavior, without modifying it. Classes should be open for

extension, but closed for modifica2on.

•  Liskov Subs2tu2on Principle –  Derived classes must be subs4tutable for their base classes and vice versa as long as they are referenced

by the same abstract interface. The base abstrac2ons must be really polymorphic.

•  Interface Segrega2on Principle –  Make fine grained interfaces that are client specific. Many client specific interfaces are be`er than one

general purpose interface

•  Dependency Inversion Principle –  Depend on abstrac4ons, not on concre4ons. Never have references or directly instan2ate concrete classes

from the class that collaborates with them, just have a references to abstrac2ons. Let other part of the program do the concrete instan2a2on and control the injec2on of the dependency object referenced as an abstrac2on.

h`p://butunclebob.com/Ar2cleS.UncleBob.PrinciplesOfOod “Uncle Bob” Robert Cecil Mar2n

But … (c++, java like languages)

•  S2ll separa2on between Coding&Design Time vs Run2me –  Should be the same : interac2ve programming

•  Once classes and interfaces are “wired” they can not be (easily) altered at run2me

•  “Cumbersome” and complex mechanisms for separa2ng instan2a2on part from execu2on part –  like spring framework, xml coding, more than 2100 classes!!

Being Closer to Alan Kay OOP idea

Smalltalk and its dialects

A dialect of Smalltalk based on the concept of Prototypes

Opensource Smalltalk

…..Only in academic environments

| myButton |!! myButton := Button new.! myButton label: 'press me'.! myButton action: [ myButton destroy ].! myButton open.!

JavaScript object model

h`p://www.ecma-‐interna2onal.org/publica2ons/files/ECMA-‐ST/Ecma-‐262.pdf

prototype-‐based language objects are Associa2ve Arrays than can vary at run2me

Being closer to OOP Alan Kay

•  Objec2ve C, Java, C# provide dynamic mechanisms, most of them inherited from smalltalk language and its tools –  java.lang.reflect, garbage collector, refactoring…

@implementation GSTimeSliderCell! !- (void)stopTracking:(NSPoint)lastPoint at:(NSPoint)stopPoint inView:(NSView *)controlView mouseIsUp:(BOOL)flag!{! if (flag) {! [[NSNotificationCenter defaultCenter] postNotificationName:GSMouseUpNotification object:self];! }! [super stopTracking:lastPoint at:stopPoint inView:controlView mouseIsUp:flag];!}! !@end!

Being closer to OOP Alan Kay

•  Actors model –  Proposed by by Carl HewiK in 1973 –  Actors are ac2ve objects which communicate by message passing

•  Erlang, Scala

Conclusions

•  We have been too platonic and having imperfect realiza2ons of the OOP idea

•  We should try to be more aristotlelic, focusing on objects as message processors with late binding

•  Be aware of the Compu2ng Science History – Most of what we think is modern was invented in the 70s

The Object Oriented Paradigm in perspective

Software

Transcript of The Object Oriented Paradigm in perspective