Herencia = Clase base de todos los problemasJ. Daniel Garcia Grupo ARCOS Universidad Carlos III de...

Herencia = Clase base de todos los problemas

Herencia = Clase base de todos losproblemas

La Programación Orientada a Objetos debe morir

J. Daniel Garcia

Grupo ARCOSUniversidad Carlos III de Madrid

3 de noviembre de 2014

cbed – J. Daniel Garcia – ARCOS@UC3M ([email protected]) – Twitter: @jdgarciauc3m 1/51

[email protected]

@jdgarciauc3m


Aviso

c Esta obra está bajo una Licencia Creative CommonsAtribución-NoComercial-SinDerivar 4.0 Internacional.

b Debes dar crédito en la obra en la forma especificadapor el autor o licenciante.

e El licenciante permite copiar, distribuir y comunicar pú-blicamente la obra. A cambio, esta obra no puede serutilizada con fines comerciales — a menos que se ob-tenga el permiso expreso del licenciante.

d El licenciante permite copiar, distribuir, transmitir y co-municar públicamente solamente copias inalteradas dela obra – no obras derivadas basadas en ella.


[email protected]

@jdgarciauc3m


ARCOS@uc3m

UC3M: Una universidad joven, internacional y orientada ala investigación.ARCOS: Un grupo de investigación aplicada.

Líneas: Computación de altas prestaciones, Big data,Sistemas Ciberfísicos, y Modelos de programación para lamejora de las aplicaciones

Mejorando las aplicaciones:REPARA: Reengineering and Enabling Performance andpoweR of Applications. Financiado por Comisión Europea(FP7).RePhrase: REfactoring Parallel Heterogeneous ResourceAware Applications. Financiado por Comisión Europea(H2020).

Normalización:ISO/IEC JTC/SC22/WG21. Comité ISO C++.


[email protected]

@jdgarciauc3m


Introducción

1 Introducción

2 Observaciones

3 Caso práctico


[email protected]

@jdgarciauc3m


Introducción

Lenguajes de programación

There are only two kinds of languages: the ones peoplecomplain about and the ones nobody uses.

Bjarne Stroustrup

Anybody who comes to you and says he has a perfectlanguage is either naïve or a salesman.

Bjarne Stroustrup


[email protected]

@jdgarciauc3m


Introducción

Herramientas y problemas

Un martillo es fantástico para clavar un clavo.

¿Y para apretar tuercas?¿Y para atornillar?¿Para depurar un programa?

¿Será la OO un martillo para programadores?


[email protected]

@jdgarciauc3m


Introducción


Un martillo es fantástico para clavar un clavo.¿Y para apretar tuercas?

¿Y para atornillar?¿Para depurar un programa?



[email protected]

@jdgarciauc3m


Introducción


Un martillo es fantástico para clavar un clavo.¿Y para apretar tuercas?¿Y para atornillar?

¿Para depurar un programa?



[email protected]

@jdgarciauc3m


Introducción


Un martillo es fantástico para clavar un clavo.¿Y para apretar tuercas?¿Y para atornillar?¿Para depurar un programa?



[email protected]

@jdgarciauc3m


Introducción

Los orígenes

La subrutina:David Wheeler y Maurice Wilkes. 1951.

Programación funcional:Lisp, Johh McCarthy. 1958.

Programación orientada a objetos:Simula, Simula-67. Ole-Johan Dahl y Kristen Nygaard.1960-1970.Smalltalk, Smalltalk-80. Alan C. Kay. 1970-1980.. . .

Programación genérica:CLU. Barbara Liskov. 1974.Ada. Jean Ichbiah. 1983.C++. Bjarne Stroustrup. 1983. Alexander Stepanov. 1998.


[email protected]

@jdgarciauc3m


Introducción

¿pero cuando tiene éxito?

1979-1983: C++.1986: Object Pascal.1986: Eiffel.1995: Java.1995: Ada95.2000: C#.


[email protected]

@jdgarciauc3m


Introducción

¿Qué más ocurrió en los 90?


[email protected]

@jdgarciauc3m


Observaciones

1 Introducción

2 Observaciones

3 Caso práctico


[email protected]

@jdgarciauc3m


Observaciones

OO: Lenguajes vs Sistema

¿Se puede hacer desarrollo OO sin un lenguaje OO?

En teoría: SI.Y en la práctica también:

X-Windows System, OSF/Motif.

Sin embargo: demasiado complicado y conducente aerrores.

Fácil cometer errores.¿Por qué dejar al programador tareas que puede hacer uncompilador?


[email protected]

@jdgarciauc3m


Observaciones


¿Se puede hacer desarrollo OO sin un lenguaje OO?En teoría: SI.

Y en la práctica también:X-Windows System, OSF/Motif.




[email protected]

@jdgarciauc3m


Observaciones


¿Se puede hacer desarrollo OO sin un lenguaje OO?En teoría: SI.Y en la práctica también:

X-Windows System, OSF/Motif.




[email protected]

@jdgarciauc3m


Observaciones

Cosas que a veces olvidamos

Principios de diseño de X-Windows ( Bob Scheifler y JimGettys, 1984).

Do not add new functionality unless an implementor cannotcomplete a real application without it.It is as important to decide what a system is not as todecide what it is. Do not serve all the world’s needs.The only thing worse than generalizing from one example isgeneralizing from no examples at all.If a problem is not completely understood, it is probablybest to provide no solution at all.If you can get 90 percent of the desired effect for 10 percentof the work, use the simpler solution.Isolate complexity as much as possible.Provide mechanism rather than policy.


[email protected]

@jdgarciauc3m


Observaciones

Todo tiene que ser un método

¿Por qué tenemos clases?

Principio de la ocultación de la información. David Parnas(1972)

Incrementar la flexibilidad y comprensión.Reducir tiempo de desarrollo.Reducir acoplamiento global.

Pero ...Hemos asumido que el módulo o componente esequivalente a la clase.Y nos empeñamos en ocultar, incluso cuando no hay nadaque ocultar.


[email protected]

@jdgarciauc3m


Observaciones


¿Por qué tenemos clases?Principio de la ocultación de la información. David Parnas(1972)




[email protected]

@jdgarciauc3m


Observaciones




Pero ...Hemos asumido que el módulo o componente esequivalente a la clase.

Y nos empeñamos en ocultar, incluso cuando no hay nadaque ocultar.


[email protected]

@jdgarciauc3m


Observaciones






[email protected]

@jdgarciauc3m


Observaciones

Métodos de clase

Un método de la metaclase → Compartido por todas lainstancias.

Java

public final class Math {public static double abs(double a) {/∗...∗/}

}

// Invocaciónx = Math.abs(y);

C++

namespace std {double abs(double arg);

}

// Invocación

x = abs(y);

Tendemos a inventar clases:Porque en alguna clase tengo que meter esto.

O a tener animales como la clase Integer.O a hacer que main sea un método.


[email protected]

@jdgarciauc3m


Observaciones

Métodos de clase


Java


}


C++


}

// Invocación

x = abs(y);


O a tener animales como la clase Integer.

O a hacer que main sea un método.


[email protected]

@jdgarciauc3m


Observaciones

Métodos de clase


Java


}


C++


}

// Invocación

x = abs(y);


O a tener animales como la clase Integer.O a hacer que main sea un método.


[email protected]

@jdgarciauc3m


Observaciones

Ocultación paranóica de la información

Los atributos de una clase siempre tiene que ser privados.

Y luego lo llenamos todo de getter y setters.¿Dónde está la ocultación de la información?

Un par de valores

class pair {public:

pair ( int k, const string & v);void set_key(int k) { key=k; }int get_key() const { return key; }void set_value(const string & v) { value=v; }string get_value() const { return value; }

private:int key;string value;

};

O un par de valores

struct pair {pair ( int k, const string & v);int key;string value;

};


[email protected]

@jdgarciauc3m


Observaciones


Los atributos de una clase siempre tiene que ser privados.Y luego lo llenamos todo de getter y setters.

¿Dónde está la ocultación de la información?

Un par de valores

class pair {public:



};

O un par de valores


};


[email protected]

@jdgarciauc3m


Observaciones


Los atributos de una clase siempre tiene que ser privados.Y luego lo llenamos todo de getter y setters.¿Dónde está la ocultación de la información?

Un par de valores

class pair {public:



};

O un par de valores


};


[email protected]

@jdgarciauc3m


Observaciones

Y entonces llegaron los patrones

Design Patterns: Elements of Reusable Object-OrientedSoftware.Erich Gamma, Richard Helm, Ralph Johnson y JohnVlissides. 1994.

Debería ser de obligada lectura.Desgraciadamente usado malamente como un recetario.

Sin embargo, hay patrones problemáticos:Singleton: Mecanismo complicado de emulación devariables globales.Visitor: Mecanimso complicado de emulación depolimorfismo dinámico múltiple.


[email protected]

@jdgarciauc3m


Observaciones



Debería ser de obligada lectura.

Desgraciadamente usado malamente como un recetario.



[email protected]

@jdgarciauc3m


Observaciones



Debería ser de obligada lectura.Desgraciadamente usado malamente como un recetario.



[email protected]

@jdgarciauc3m


Observaciones

Herencia

Herencia: Mecanismo de reutilización de código.Herencia de interfaz (Subtyping): Establece una relaciónes-un.Herencia de implementación: Mecanimso de reutilizaciónde implementación.

Aproximaciones:Todo deben ser clases organizadas en una única jerarquíaunversal.

Un Vector extiende un AbstractList que extiende unAbstractCollection que extiend un Object.

Utilizar herencia de forma limitada cuando sea necesario.Un std::vector no hereda nada de nadie.


[email protected]

@jdgarciauc3m


Observaciones

Polimorfismo

Polimorfismo: Capacidad de ofrecer el mismo interfazvariando la implementación.

Normalmente usado como sinónimo de polimorfismodinámico.

Polimorfismo dinámico: Se toma la decisión sobre laselección de la implementación en tiempo de ejecución.

Pequeño sobrecoste por invocación a función.Aceptable si el uso es limitado.

Conduce a diseños más flexible de lo realmente necesario.Y si un día . . .


[email protected]

@jdgarciauc3m


Observaciones

Polimorfismo

Polimorfismo: Capacidad de ofrecer el mismo interfazvariando la implementación.Normalmente usado como sinónimo de polimorfismodinámico.

Polimorfismo dinámico: Se toma la decisión sobre laselección de la implementación en tiempo de ejecución.

Pequeño sobrecoste por invocación a función.Aceptable si el uso es limitado.

Conduce a diseños más flexible de lo realmente necesario.Y si un día . . .


[email protected]

@jdgarciauc3m


Observaciones

Hay otro polimorfismo

Polimorfismo estático: Se toma la decisión sobre laselección en tiempo de compilación.

No siempre es posible.Flexibilidad suficiente.No hay sobrecoste en tiempo de ejecución.

Ordenación genérica

template <typename C>void sort(C & c) {

sort (c.begin() , c.end()) ;}


[email protected]

@jdgarciauc3m


Observaciones

Hacia un nuevo paradigma

A new scientific truth does not triumph by convincing itsopponents and making them see the light, but ratherbecause its opponents eventually die

The structure of scientific revolutionsThomas Kuhn, 1962.

FUNGENOOP.Functional.Generic.Object Oriented.Procedural.

(Tony DaSilva)

Ejemplo

void draw_all(Container & c)requires same_type<value_tye<Container>,Shape∗>()

{for_each(c, []( Shape ∗ s) { s−>draw();});

}


[email protected]

@jdgarciauc3m


Observaciones

Un problema adicional

Gestión de los recursos.Muchos lenguajes OO han optado por hacerle la vida fácilal programador con la recolección de basura.

Pero seguimos con memory leaks por todas partes.

La recolección de basura:Generalmente tiene impacto en el rendimiento.Incremento del imapcto debido a la revolución multi-core.La mejor estrategia de gestión de la basura es no generarbasura.


[email protected]

@jdgarciauc3m


Caso práctico

1 Introducción

2 Observaciones

3 Caso práctico


[email protected]

@jdgarciauc3m


Caso práctico

El problema

3 Caso prácticoEl problemaUna solución sencillaSolución orientada a objetosSolución genéricaPolimorfismo de implementaciónComparación


[email protected]

@jdgarciauc3m


Caso práctico

El problema

Un caso sencillo

Un documento tiene una lista de elementos.Queremos volcar un elemento a la salida estándar.

Usaremos una función dump().Comenzaremos usando números enteros como valores deelementos.

NOTA: Las soluciones que se presentan se derivan deadaptaciones de las presentadas por Sean Parent en su charla“value semantics”.


[email protected]

@jdgarciauc3m


Caso práctico

Una solución sencilla



[email protected]

@jdgarciauc3m


Caso práctico


Código cliente

main.cpp

#include "doclib.h"#include <iostream>

int main() {document doc;doc.add_element(1);doc.add_element(2);doc.add_element(3);

doc.dump(std::cout);

return 0;}


[email protected]

@jdgarciauc3m


Caso práctico


Biblioteca de documentos

doclib.h

#ifndef DOCLIB_H#define DOCLIB_H

#include <vector>#include <iostream>

class document {public:

void add_element(int e) { elems.emplace_back(e); }void dump(std::ostream & out) const;

private:std :: vector<int> elems;

};

#endif


[email protected]

@jdgarciauc3m


Caso práctico



doclib.cpp

#include "doclib.h"

void document::dump(std::ostream & out) const {using namespace std;out << "START" << endl;for (const auto & e : elems) {

out << e << endl;}out << "END" << endl;

}


[email protected]

@jdgarciauc3m


Caso práctico

Solución orientada a objetos



[email protected]

@jdgarciauc3m


Caso práctico


Generalizando la biblioteca

Deseamos tener una solución más general.Soportar documentos con elementos de distintos tipos(enteros, cadenas, . . . ).Soportar documentos que permitan elementos conmúltiples tipos en el mismo documento.

Probemos la solución orientada a objetos clásica.


[email protected]

@jdgarciauc3m


Caso práctico



doclib.h


#include <iostream>#include <vector>#include <memory>

class element {public:

virtual ~element() {}virtual void dump(std::ostream &) const = 0;

};

//. . .


[email protected]

@jdgarciauc3m


Caso práctico



doclib.h


void add_element(std::shared_ptr<element> && e) { elems.emplace_back(e); }void dump(std::ostream & out) const;

private:std :: vector<std ::shared_ptr<element>> elems;

};

#endif


[email protected]

@jdgarciauc3m


Caso práctico


Código cliente

main.cpp

#include "doclib.h"

class my_int_value : public element {public:

my_int_value(int v) : value{v} {}

void dump(std::ostream & out) const {out << value << std::endl;

}

private:int value;

};

//. . .


[email protected]

@jdgarciauc3m


Caso práctico


Código cliente

main.cpp

int main() {using namespace std;

document doc;doc.add_element(make_shared<my_int_value>(1));doc.add_element(make_shared<my_int_value>(2));doc.add_element(make_shared<my_int_value>(3));doc.dump(cout);

return 0;}


[email protected]

@jdgarciauc3m


Caso práctico


Polimorfismo dinámico

Al usar la herencia como mecanismo para el polifmorfismose traslada la complejidad al código cliente,incrementando el acoplamiento.La herencia implica tamaños variables → Memoriadinámica.Indirección + memoria dinámica + virtualización →rendimiento pobre.Gestión del tiempo de vida → recolección de basura ocuenta de referencias.Propiedad compartida de objetos → estructuras de datosaccidentales.Adicionalmente: Problemas de sincronización.

La herencia es la clase base de todos los males.


[email protected]

@jdgarciauc3m


Caso práctico

Solución genérica



[email protected]

@jdgarciauc3m


Caso práctico

Solución genérica

Programación genérica

Probemos el polimorfismo en tiempo de compilación.Un tipo genérico document<T> usable para cualquier tipoT.Se apoya en una función genérica para volcar valoresdump_value().

Permite tener documentos homogéneos.No se pueden tener enteros y cadenas en el mismodocuemnto.Todas las llamadas resueltas en tiempo de compilación.


[email protected]

@jdgarciauc3m


Caso práctico

Solución genérica


doclib.h


#include <iostream>#include <vector>

template <typename T>void dump_value(const T & x, std::ostream & out) {

out << x << std ::endl;}

//. . .


[email protected]

@jdgarciauc3m


Caso práctico

Solución genérica


doclib.h

template <typename T>class document {public:

void add_element(T && e) { elems.emplace_back(e); }void dump(std::ostream & out) const;

private:std :: vector<T> elems;

};

template <typename T>void document<T>::dump(std::ostream & out) const {

using namespace std;out << "START" << endl;for (const auto & e : elems) {

dump_value(e,out);}out << "END" << endl;

}

#endifcbed – J. Daniel Garcia – ARCOS@UC3M ([email protected]) – Twitter: @jdgarciauc3m 39/51

[email protected]

@jdgarciauc3m


Caso práctico

Solución genérica

Código cliente

doclib.h

#include "doclib.h"#include <string>

int main() {document<int> doc1;doc1.add_element(1);doc1.add_element(2);doc1.dump(std::cout);

document<std::string> doc2;doc2.add_element("C++");doc2.add_element("is");doc2.add_element("cool");doc2.dump(std::cout);

return 0;}


[email protected]

@jdgarciauc3m


Caso práctico

Polimorfismo de implementación



[email protected]

@jdgarciauc3m


Caso práctico


Ocultando el polimorfismo

El polimorfismo dinámico debe ser un mecanismo deimplementación.

No debe ser visible al código del cliente.El cliente debe usar interfaces simplificadas.

Usaremos un document que acepta elements.

Internamente un element puede usar polimorfismodinámico como detalle de implementación.

Borrado de tipos.


[email protected]

@jdgarciauc3m


Caso práctico



doclib.h


#include <iostream>#include <vector>#include <memory>

template <typename T>void dump_value(const T & x, std::ostream & out) {

out << x << std ::endl;}

// . . .


[email protected]

@jdgarciauc3m


Caso práctico


Elemento: Internamente puntero a valor

doclib.h

class element {public:

template <typename T>element(T x);

element(const element & o) = delete;element & operator=(const element & o) =delete;

element(element &&) noexcept = default;element & operator=(element &&) noexcept = default;

void dump(std::ostream & out) const { self−>dump(out); }

// . . .private:

std :: unique_ptr<base_value> self;};


[email protected]

@jdgarciauc3m


Caso práctico


Detalle de implementación: Jerarquía de valores

doclib.h (detalles de element)

private:

struct base_value {virtual ~base_value() = default;virtual void dump(std::ostream & out) const = 0;

};

template <typename T>struct value : base_value {

value(T x) : data{std :: move(x)} {}virtual void dump(std::ostream & out) const { dump_value(data,out); }T data;

};

// . . .


[email protected]

@jdgarciauc3m


Caso práctico



doclib.h

// . . .template <typename T>element::element(T x) :

self {std :: make_unique<value<T>>(std::move(x))}{}


void add_element(element && e) { elems.emplace_back(std::move(e)); }void dump(std::ostream & out) const;

private:std :: vector<element> elems;

};

#endif


[email protected]

@jdgarciauc3m


Caso práctico


Volcado de documento

doclib.cpp

#include "doclib.h"

void document::dump(std::ostream & out) const {using namespace std;out << "START" << endl;for (const auto & e : elems) {

e.dump(out);}out << "END" << endl;

}


[email protected]

@jdgarciauc3m


Caso práctico


Un documento heterogéneo

main.cpp

#include "doclib.h"

int main() {document doc;doc.add_element(1);doc.add_element(2);doc.add_element("C++");doc.add_element("is cool");doc.dump(std::cout);

return 0;}


[email protected]

@jdgarciauc3m


Caso práctico

Comparación



[email protected]

@jdgarciauc3m


Caso práctico

Comparación

Uso de memoria

Solución mínima.3 asignaciones.28 bytes.

Solución OO clásica.6 asignaciones.208 bytes.

Solución genérica.3 asignaciones.28 bytes.

Polimorfismo de implementación.6 asignaciones.104 bytes.


[email protected]

@jdgarciauc3m


Caso práctico

Comparación

Herencia = Clase base de todos losproblemas

La Programación Orientada a Objetos debe morir

J. Daniel Garcia

Grupo ARCOSUniversidad Carlos III de Madrid

3 de noviembre de 2014


[email protected]

@jdgarciauc3m

Herencia = Clase base de todos los problemasJ. Daniel Garcia Grupo ARCOS Universidad Carlos III de...

Documents

Transcript of Herencia = Clase base de todos los problemasJ. Daniel Garcia Grupo ARCOS Universidad Carlos III de...