Resumenes al grano de la bibliografía que se evaluó en el 2do cuatri de 2024 de inge 1.
https://www.isw2.com.ar/bibliografia-1/papers
Naur dice que los programas son como teorías: son un modelo que alguien concibió en algún momento, y no se plasman completamente en texto. Esto también quiere decir que pueden “morir”. Cuando no hay alguien que pueda de describir la teoría y solo queda el texto, está “muerto”. Esto solo se puede notar a la hora de modificar y extender dicho programa.
Don Norman explica que el principio del buen diseño es proveer un buen modelo conceptual a partir de affordances, mappings y constraints, y hacerlas visibles.
Según Brooks en este paper, hacer software tiene complejidades inherentes que ponen una cota inferior en cuanto tarda en desarrollarse. No hay “bala de plata” para solucionarlas. Algunas causas de la complejidad no-accidental:
Si hay complejidades accidentales. Algunas ya están resueltas, gracias lenguajes más útiles para el programador, time-share e IDEs. Otras el autor especulaba que se atacarían en el futuro, con aún mejores lenguajes, OOP, AI, sistemas expertos, programación automática, programación gráfica, verificación formal, mejores ambientes y herramientas y mejores estaciones de trabajo.
La esencia conceptual de un problema, la complejidad no-accidental, se puede atacar con reusar y ampliar soluciones ya existentes, adoptar modelos de desarrollo más iterativos y de rápido prototipado, con mejorar el diseño en general buscando y fomentando el desarrollo de buenos diseñadores.
Self, descrito en su paper, es un lenguaje basado en prototipos. No suscribe a la forma de categorización platónica sino a la aristotélica, es decir no hay clases, solo objetos concretos.
Surge como dialecto de Smalltalk e impulso la idea de máquinas virtuales, compilación JIT, el GUI toolkit morphic y GC, entre otras.
El lenguaje se desarrolla a partir de un método parecido al de investigación científica.
Basado en metáforas y el lenguaje humano.
Este tipo define la ingeniería de software como: el solucionar problemas con software de forma eficiente, en tiempo y costo, con un enfoque científico y empírico.
Aplicar esto requiere ser experto en aprender y en manejar complejidad. Iteración, feedback, incrementalismo, experimentación e empiricismo son las claves para aprender. Modularidad, cohesión, separation of concerns, abstracción y poco acoplamiento.
Muchas medidas como velocity, líneas de código o cobertura de tests son irrelevantes o incluso contraproducentes. El propone medir:
Woolf define que dos métodos son polimórficos cuando comparten nombre y comportamiento, cuando hacen esencialmente lo mismo. También lo son dos clases cuando entienden varios de los mismos mensajes y los responden de igual manera. Si se les creara una superclase que implemente esa interfaz común, que no tenga como objetivo ser instanciada nunca, esa sería la template class de una jararquía polomórfica.
Normalmente, una colaboración solo ataja polimorfismo del lado del receptor (le puedo mandar el mismo mensaje a varios, distintos, objetos polimórficos). Dan Ingalls propone usar doble dispatch, donde el receptor manda un nuevo mensaje al emisor, que ahora pueden ser distintos objetos polimórficos. Para lograr esto en Smalltalk, el emisor original se manda a si mismo como argumento.
Woolf ve el problema de que a veces una clase espera un colaborador, pero se quiere poder no tenerlo. Se podría representar con que el colaborador sea nil, pero genera mucho código defensivo y es poco escalable. Bobby propone usar Null objects, objetos que implementan los mensajes de la clase del colaborador, pero no hacen nada (“hacer nada” en la forma más apropiada para el contexto).
Para un object se puede implementar con una jerarquía #AbstractObject con subclases #RealObject y #NullObject (a lo Polymorpic Hierarchies). También se puede implementar con un#RealObject y #NullObject subclasificando de el; menos semántico pero también menos engorroso.
Woolf propone que los objetos deleguen pedidos complicados de forma polimórfica entre sus colaboradores. Esto genera código flexible y bien encapsulado. Un ejemplo es la comparación de objetos.
Esta colaboración tiene un iniciator, un handler, recursers y terminators.
Beck explica que cuando tenés un método muy grande y complejo, refactorizarlo en otros más chicos resultar engorroso porque arrastrás parámetros y variables temporales por todos lados.
Propone encapsular al método en un objeto, dandole al método su propio namespace donde puede hacer que los argumentos y varibles sean colaboradores internos. Tendría un método #compute que retornaría su resultado.
Estos objetos no suscriben al patrón de antropomorfizar. No son sustantivos, son verbos.
Al chabon le gustan los patrones. Solo eso.
Concluye que la carrera de ciencias de la computación creció a costa de su calidad y seriedad de la enseñanza y de su curricula.
Esto pasó por varios motivos. Uno es que la cantidad de profesores instruidos posta nunca bastaron para la cantidad de departamentos de computación en distintas universidades. También por la falta de curiosidad intelectual, desplazada por puja de la industria y el poco “amor al arte” que le tienen estudiantes, que comúnmente solo estudian por necesidades económicas y sociales.
© 2020-2025 Ramiro. Contenido disponible bajo CC BY-SA 4.0.
Capaz flasheo, pero me da medio chanta este chabon. Capitulos enteros parecen sacados de una charla de Glenn Vanderburg del 2010. Cita otra del 2018, pero para un parrafico, no como fuente de medio libro.
https://www.youtube.com/watch?v=NP9AIUT9nos
Y todo dicho en un tono muy autoritativo, repetitivo y con prosa de blog. No me genera mucha confianza.
↩