tag:blogger.com,1999:blog-1919596727860015236.post6324631611692075081..comments2023-09-19T01:08:12.937-07:00Comments on cosas de jb: Jerarquias (Object Based)jbhttp://www.blogger.com/profile/13709249214033017810noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-1919596727860015236.post-50676812485538315562007-11-16T19:25:00.000-08:002007-11-16T19:25:00.000-08:00gracias ikariel por tu comentario. Estoy muy conte...gracias ikariel por tu comentario. Estoy muy contento por que claramente el post original permitio que se nos muevan un par de conexiones en nuestro cerebro, y pensar ciertas cosas de otra manera :)<BR/>Tambien me gusto mucho la comparacion con induccion/deduccion. <BR/>Con respecto a cual de las dos formas es mas dolorosa, creo que hay que tener en cuenta, que los lenguajes orientados a objetos (o basados en objetos), refuerzan la construccion de clases y jerarquias siguiendo la estructura "es subespecie de", por lo que, utilizar otro tipo de preorden (ja, lo dije!) para crear la estructura puede ser doloroso (palabra suficientemente descriptiva).<BR/>Insisto en que es algo de los lenguajes (de los que conosco yo, al menos), y, en principio, no seria del preorden.<BR/>Aunque, el preorden "es subespecie de", facilita ponerle nombres al conjunto de elementos que definen a la clase. Eso es un punto a favor de esa aproximacionjbhttps://www.blogger.com/profile/13709249214033017810noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-4041479397996248472007-11-15T18:09:00.000-08:002007-11-15T18:09:00.000-08:00Creo que a la conclusión que llegaste está relaci...Creo que a la conclusión que llegaste está relacionada con dos procesos de razonamiento que van en distinto sentido.<BR/><BR/>El primer ejemplo que das, el de a partir de un concepto abstraerlo en una clase, y de ahí a las subclases, podríamos vincularlo con la deducción (De lo universal a lo particular). Donde de un modelo inferís las características de las particularidades.<BR/><BR/>El segundo lo podés ver como inducción, de un conjunto de elementos obtenés el patrón común que te permite meterlos a todos en un conjunto.<BR/>Creo que estas dos formas de razonar están vinculadas con la manera de crear clases.<BR/><BR/>En mi experiencia particular, he encontrado que la deducción es una manera más segura de crear la clase, ya que el concepto es conocido y si cambia la clase, lo va a hacer acorde al concepto. <BR/>En el segundo caso te basas en un conjunto de ejemplos, que puede no ser completo y quizás te encuentres con que no generalizaste bien (por lo que un refactor puede ser muy doloroso). En los casos de inducción suele ser menos doloros usar composición para extraer el comportamiento, ya que un cambio en la clase inducida, no produce un cambio estructural (pero puede ser igual de doloroso).D Garciahttps://www.blogger.com/profile/07805293182193800469noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-88659906932143632832007-11-09T21:29:00.000-08:002007-11-09T21:29:00.000-08:00gracias a manuk, encontre que existe algo sobre su...gracias a manuk, encontre que existe algo sobre subject oriented programming. En este paradigma, creo, la jerarquia esta definida desde cada sujeto (subjetiva), me parecio piola: http://en.wikipedia.org/wiki/Subject-oriented_programmingjbhttps://www.blogger.com/profile/13709249214033017810noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-87311654041432096292007-10-18T22:34:00.000-07:002007-10-18T22:34:00.000-07:00Que tienes para aportar sobre el aproach bottom up...Que tienes para aportar sobre el aproach bottom up?<BR/>Visita my flog.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-38847943425517423662007-10-18T13:47:00.000-07:002007-10-18T13:47:00.000-07:001- C++ no existe mas mis polainas.2- conozco tanto...1- C++ no existe mas mis polainas.<BR/>2- conozco tantos licenciados que meten la pata una y otra vez... eso ya no es garantia de nada. <BR/>3- Te lo dice un casi licenciado.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-43422349020381016272007-10-17T08:34:00.000-07:002007-10-17T08:34:00.000-07:00Que grande Anonymous!! jajajaA mi me gusto lo de l...Que grande Anonymous!! jajaja<BR/><BR/>A mi me gusto lo de las tetas, siempre me gustaron las tetas y la idea de mezclar tetas y pc junta 2 vicios increibles.<BR/><BR/>Grande JB jejeje<BR/><BR/>Ano, da la cara :PSergio Millerhttps://www.blogger.com/profile/05318087381297675306noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-81376714820554562372007-10-17T05:48:00.000-07:002007-10-17T05:48:00.000-07:00Muy bueno!Muy bueno!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-37816385724747763532007-10-16T21:20:00.000-07:002007-10-16T21:20:00.000-07:00b)Cool? buena onda? No esperes eso de mi.c)Seguimo...b)Cool? buena onda? No esperes eso de mi.<BR/><BR/>c)Seguimos en inglés ? <BR/><BR/>d)Las metaforas son peligrosas no es fácil usar buenas metaforas y no se puede usar cualquier metafora con cualquier interlocutor.<BR/><BR/>Hablar de jerarquías está bien para una clase de introducción a la idea de los objetos y sus posibilidades de reuso de código. Se acuerdan de C++ y de los zip drive? Bueno ya pasó.<BR/>La jerarquía de clases es una manera, quien la propone trata de explicarla con metaforas. No reusemos esas metaforas para buscar nuevas formas de reusabilidad. No existe la jerarquía en nuestros problemas y nos obliga a volcarla en nuestro modelo, nosotros inventamos la jerarquía la usamos como herramienta debería ser una de tantas otras como la composición y algunos otros patrones.<BR/>La jerarquía como usted dice es una manera de resolver el problema de la resusabilidad. Solo una y tal vez pésima tal vez nunca fue buena idea.<BR/>En tu comentarioa a partir de "el problema existe.." no entendí nada de lo que quieres decir.<BR/>Y esto te lo esta diciendo un licenciado.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-66089906668905883842007-10-16T10:18:00.001-07:002007-10-16T10:18:00.001-07:00No estoy de acuerdo con el problema de las metafor...No estoy de acuerdo con el problema de las metaforas. Por eso son metaforas. Cuando alguien intenta dar un salto cualitativo en una disciplina (principalmente en algo como la computacion, o el paradigma de objetos) las metaforas simples ayudan. Imaginate que para ejemplificarte esquemas de herencia o subespecies me ponga a hablar de tipos de cuenta bancaria, describiendo exhaustivamente como es cada una, que funcionalidades deberia ofrecer... O incluso alguno bien intrincado como los que mencionas "de la vida real". Se pierde el punto, vas a tardar mas tiempo pensando en los detalles de lo que queres modelar antes que en como modelarlo. <BR/>A mi me gustan esas metaforas, son 100% adecuadas para ejemplificar conceptos nuevos. Adelante por mi.<BR/><BR/>GutesAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-27241897765318623912007-10-16T10:18:00.000-07:002007-10-16T10:18:00.000-07:00This comment has been removed by the author.Guteshttps://www.blogger.com/profile/15873495153879395915noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-77221676677475128762007-10-15T11:46:00.000-07:002007-10-15T11:46:00.000-07:00Hola anonymous:a) El ejemplo de la composicion me ...Hola anonymous:<BR/>a) El ejemplo de la composicion me vino como anillo al dedo, era justamente lo que queria mostrar en la segunda forma de construir clases (clases en el sentido "matematico"). Entonces la composicion es una forma de resolver el problema de las clases (clases en un sentido abstracto) (y reusabilidad de codigo) de forma elegante, pero por otro lado, el problema existe de que no hay una formalizacion en muchos lenguajes OO de definir este tipo de jerarquias (la jerarquia que estas armando cuando estas componiendo), y la unica forma de jerarquizar es a travez del esquema "es subespecie de". Con esto me refieron al nivel que tiene el keyword class o sublclass en relacion a como puedas implementar una composicion.<BR/>Asi que gracias por el ejemplo<BR/><BR/>b) Che, se noto mucha mala onda... keep cooljbhttps://www.blogger.com/profile/13709249214033017810noreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-84119078802235419922007-10-15T03:10:00.000-07:002007-10-15T03:10:00.000-07:00La jerarquia de clases suena bien en las metaforas...La jerarquia de clases suena bien en las metaforas como "auto tiene cuatro ruedas,carro tambien tiene cuatro ruedas" o si hagamos el "vehiculo de cuatro ruedas". Pero eso es muy primitivo el mundo abstracto que se genera en los programas que hacemos incluso no muy complejos no es tan simple como eso. Los autos y los seres vivos tienen algunas limitaciones fisicas para su variedad que no la tienen las clases. Creo que deberiamos dejar de usar metaforas tan simples del mundo concreto para estas cosas, podemos buscar metaforas en ciencias abstractas si queremos. En el 2007 hablar todavia de cosas como mamiferos con tetas no lleva a buenas conclusiones sobre programación, despues de unos años programando se ve que son lindas esas metaforas pero solo al principio.<BR/>Un concepto simple: composicion, mucho mas poderoso que pensar en herencia. En lugar de " es un" "tiene un". Mamifero tiene tetas, muñeca de goma tiene tetas.<BR/>Muñeca de goma no es un mamifero, muñeca de goma puede ser objeto de plastico. Algunas tetas de algunos mamiferos tambien son objetos de plastico.<BR/>Esa es la conclusión.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1919596727860015236.post-45752832778635296602007-10-15T02:01:00.000-07:002007-10-15T02:01:00.000-07:00notas:1) pensar se escribe con s, no con z :)2) Cr...notas:<BR/>1) pensar se escribe con s, no con z :)<BR/>2) Creo que las dos formas de pensar la construccion de la jerarquia de clases, cuando las cosas que tienen que ir a infinito van para ese lado (tiempo), y las que tienen que ir para sero, se aproximan a cero (costo), tendrian que producir mas o menos lo mismo, pero lo que me interesa es plantear las diferencias conceptuales para aprobecharlas durante el proceso de construccion<BR/>3) La relacion que establesco con el paradigma funcional no tiene que ser necesariamente asi (y de hecho, el que sea asi produce una limitacion), eso lo puse por que tenia en mente la implementacion de trait de squeak, pero las clases pueden compartir cosas distintas a comportamiento para poder definir una superclase a ellas (gracias Manuk!)jbhttps://www.blogger.com/profile/13709249214033017810noreply@blogger.com