¿Alguien tiene ejemplos de programas POO?

[Rafael Villar Burke]

Jesus Rodriguez wrote:
> Hola a todos, voy a intentar responder lo mejor posible :)
>
>
> Chema:
>
> Los patrones, bueno, la verdad es que no me he mirado niguno, no pensé
> que
> hiciera falta :P
No es que hagan falta, es una colección de soluciones útiles para evitar
que reinventes todo. Eso sí, es cierto que hay mucha jerga a su
alrededor, cuando los conceptos que señala son en realidad bastante
sencillos. Búscate varias fuentes distintas para entenderlo.
> Rafael:
>
> Sobre TDD (test-driven programming) he leido sobre eso en "dive into
> python", la verdad es que está bastante bien, aunque el ejemplo era un
> programa de 2 funciones y claro, no sabría aplicarlo bien a un
> programa con
> varios modulos y clases (sería quizás hacer las pruebas a todo el
> programa a
> la vez? o testear modulo por modulo?
Lo que has visto ahí es la creación de test unitarios... la metodología
de la programación guiada por tests combina la creación de tests, con
una forma de desarrollar el código y la refactorización. En pocas
palabras es: haz un test que no funcione, implementa el mínimo código
que haga que funcione (como sea), refactoriza si hay duplicación de
código, empieza de nuevo.

> También he leido sobre refactorización, pero estoy en las mismas, como
> novato que soy no me he visto capaz de usar las tecnicas más sotisficadas.
Las más sencillas suelen valer para casi todo.
>
> Sobre los casos de uso, aun leyendo el enlace, no me ha quedado nada
> claro
> de lo que es.
Pues es como hacer un juego de rol con tu problema :). Por ejemplo:
- Va un cliente y llega a la pantalla del cajero y tiene que
identificarse para obtener el saldo.
- El cliente quiere hacer una transferencia
- El cliente quiere un extracto de los últimos movimientos
....
De ahí puedes pensar: ¿qué datos necesita para identificarse? ¿qué
interfaz muestra el cajero? ¿teclas, pantalla táctil? ¿una tecla para
cada operación? ¿pocas teclas y distintos modos?, ¿qué operaciones van a
ser necesarias? ¿qué hace el cliente (su interfaz)? ¿qué hace el cajero
(su interfaz)? ¿hay algún actor más (la central/base de datos)? ¿con
quién se relaciona? ¿con el cliente o con el cajero, que, a su vez, hace
de intermediario (proxy/fachada)? ¿cómo se devuelven los datos? ¿en un
ticket? ¿encendiendo distintas lucecitas cada una con un significado?....
>
> Sobre lo de leer código ajeno, pues eso entra parte de lo que quiero
> hacer,
> pensaba ir leyendo código ajeno para ir aprendiendo.
>
> Bueno, supongo que con la practica e ir viendo los fallos de mis
> programas,
> ire mejorando.
>
> Segun he entendido, estaria bien, hacer un diagrama, o al menos tener una
> idea de que clases van a haber, que hará cada una y las relaciones entre
> ellas, y crear tests.
En definitiva... pensar un poco antes acerca del problema e intentar
plasmar esas ideas, para comprobar qué problemas surgen en lo concreto.
Intenta pensar en términos más abstractos en vez de empezar ya con las
soluciones. Es decir... es preferible que empieces pensando en que debes
resolver la identificación del usuario, la petición de operaciones del
usuario al cajero, la petición de operaciones entre cajero y central de
datos, la forma de empaquetar los datos que se devuelven.

Un libro que se puede obtener en la red y que hace una introducción muy
buena a la forma de pensar de la POO es Thinking in C++, de Bruce Eckel.
Además de enseñar C++ introduce muy bien a la programación orientada a
objetos y a los patrones de diseño. Realmente es uno de los libros
introductorios más interesantes que he leído sobre el tema.

Saludos,

Rafael Villar Burke
www.rvburke.com