🚀 go-pugleaf

Federico escribi� en mensaje <71sog8$nfi$1@talia.mad.ibernet.es>...
>Vale, es un operador, pero tambi�n hay m�todos similares. (nunca lo he
>usado)
>Voy a intentar explicar c�mo veo yo la POO:
>Consiste en analizar el problema que deseamos tratar y definir qu�
entidades
>generales hay en ese problema. Despu�s a partir de estas entidades podemos
>hallar otras nuevas (herencias, agregaciones, etc.) P.e. Situaci�n t�pica:
>"c�mo freir un huevo". Al analizar el problema encontramos qu� hay una
serie
>de elementos qu� en si mismos conforman entidades: persona, sart�n, huevo,
>aceite, cocina, cerilla, etc.. Cada uno de estos elementos (objetos) tiene
>unas caracter�sticas y una forma de "comportarse", o mejor dicho, cosas que
>puede hacer o que se pueden hacer con �l. P.e., la cerilla tiene como
>caracter�sticas (atributos) que es de madera (gralmente), que tiene una
>punta de f�sforo (por cierto la punta de f�sforo podr�a considerarse como
un
>nuevo objeto con sus m�todos de encendido y esas cosas), etc. La persona
>tendr�a como m�todos / cosas-que-puede-hacer: partir el huevo, usar el
>m�todo encender de la cerilla, etc...
>As� analizar�a yo el problema de forma OO (que conste que no me he metido a
>analizar el problema a fondo).
>Por cierto, los eventos podr�an ser "apagado de fuego", "rotura de huevo",
>etc...
>Analizado as�, pongamos que tenemos un objeto "cocinero", qu� crees que
>ser�a mejor:
>1.- Tener un m�todo "cocinar" que recibe un objeto "comida" y dentro del
>m�todo "cocinar" preguntamos (instanceof) si el objeto comida es un
"huevo",
>si es un "filete", etc y entonces hacemos unas cosas u otras.
>2.- El cocinero tiene m�todos "cocinarHuevo", "cocinarFilete"
>
>Lo mismo con los eventos. Qu� es mejor?
>1.- El cocinero recibe todos los eventos y con getSource(), instanceof, etc
>haya de qu� evento se trata.
>2.- Creamos clases adaptadoras. P.e.: OjoDelCocinero y le decimos que esta
>clase recibe los eventos de tipo visuales (p.e. para saber cu�ndo est�
hecho
>el huevo) En un esquema de POO seg�n OMT, OjoDelCocinero lo
representar�amos
>como parte del cocinero.
>
>Bueno, no s� si me habr� explicado muy bien, pero........
>
>Un saludo,
>Federico
>


    Si me tuviera que mojar por una de las dos, quizas optaria por el metodo
utilizado por JAVA. �Por que? Hemos de tener en cuenta que se estan haciendo
unas clases generales con las que puede trabajar todo el mundo y todo el
mundo podra crear sus subclases y dependencias. Por ejemplo, siguiendo tu
esquema... que pasa si hemos definido una subclase superhuevo?? Tendremos
que crear una funcion cocinarsuperhuevo, aun y cuando sus componentes no
esten redefinidos por superhuevo??
    Para solucionar esto de tu forma, tendrias que crear un funcion
cocinarsuperhuevo teniendo en cuenta funciones abstractas y todo eso. � Pero
no te aporta estas capacidades la forma de trabajar de SUN?

    Sin duda, se podria resolver de las dos formas. Pero, por la metodologia
que ha seguido JAVA, creo que es mucho mas conveniente la que utiliza. Has
de tener en cuenta, que esta metodologia se ajusta mas a una abstraccion de
datos que la que tu propones.
    Otro ejemplillo y ya ta :) ...

    Si tuvieras una lista con objetos JObjeto, con las siguientes subclases,
                                                            /           \
                                                         Patata    Melon

    Y tuvieras una operacion Agregar en la clase JLista, como lo harias?
definirias un AgregarPatata y un AgregarMelon o con la funcion
Agregar(JObjeto)  ya lo solucionarias(definiendo correctamente las
operaciones y todo eso pa que sean abstractas y eso). Pues, en la
esencia(meno que mas, el ejemplo lo he pensao en un momentito), viene a ser
lo mismo.

    Espero rechistes un poquillo , porque asi todos aprendemos mucho mas
rompiendonos el coco. No se si lo que pienso es lo correcto. Si me
convences, mas que sabre.

    Hata pronto