On 12/1/05, GallegO <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] escribió:
> Creer que en una computadora algo no está programado es como creerse
> la heladera pensante de McCarthy, comentario que dio risa a
> generaciones :)
>
> Saludos
Bueno, si sabes algo de Smalltalk el código esta en el sitio de
Smalltalking para bajarlo. Podes revisarlo vos mismo para ver si es que
esta programado. Ojo lo digo desde mi posicion de tipo simple. Yo por
ahi no se muchas cosas de las que vos podes estar consciente. El que
sabe, sabe y el que no aprende.
Quiero aclarar ademas que no me interesan en lo mas minimo estos temas
pues yo solo me dedico a programar para ganarme el pan y cuando vuelvo a
casa prendo la tele y al... sillon. Sólo di el ejemplo porque lo conocia
pero no me interesa entablar ninguna discusion cientifica al respecto.
Saludos
Gallego
PD: En la lista de Smalltalking hablan mucho sobre estos temas
Hay 2 maneras de hacer un sistema:
1. A lo BASIC: Un gran programa que hace todo, con una sola entrada y una gran salida. Variaciones de esto es un gran ciclo for que toma determinaciones de a quien llamar (lo mismo que un MCP).
2. Event Oriented Programming: Objetos que reaccionan a mensajes. Junta y pega objetos, donde cada objeto tiene muy poca responsabilidad y unos pocos objetos colaboradores. Si además los colaboradores se pueden inyectar (es decir, configurar de alguna manera) los comportamientos se pueden extender de cualquier manera que sea necesario.
Lo que voy a decir es a título personal, una intuición que no he comprobado, pero que me parece cada vez más verdadera: "Un sistema no es orientado a objetos si:
1. No existe el polimorfismo.
2. No se aplican los patrones de diseño factory method, template method y strategy.
3. No se utilizan pruebas unitarias con JUnit o SUNit.
Puedo estar equivocado, pero sin polimorfismo de nada sirve la herencia y el encapsulamiento. Sin patrones de diseño el código se transforma en un enredo con decisiones de diseño repartidas por todo el código (la misma decisión en muchas partes => cambiar una decisión tiene un costo muy alto). La falta de pruebas unitarias hace que el código no se pueda modificar con confianza y por ende se pierde agilidad.
Saludos,
Guillermo.
