Software

Modelo computable de un dominio de conocimiento de la Realidad. Modelado de la realidad

mediante lenguaje de máquinas. El objetivo es representar un dominio de la realidad para
entender comportamientos y poder predecir.
“Hacer buen software es hacer buen modelo”

Lenguajes de programación

Metacirculares
Escritos en sí mismos, usando su mismo lenguaje. EJ: Smalltalk

Feedback Inmediato
Conocer casi en tiempo real si lo que escribimos es correcto o no. EJ: Test-Driven
Development.

Tipos de lenguajes según el chequeo de tipos

________________________________________
Cuándo | Static | Dynamic |
Qué | | |
________________________________________ |
Strong | Java/C# | Python/Smalltalk |
(paro la | | |
ejecución) | | |
___________ |______________ |____________________________ |
Weak | C/C++ | Visual Basic 6 |
(que el | | (MALO) |
programador | | |
decida. Tira | | |
warnings) | | |
___________ |_______________|___________________________ |

Modelo
Mal Modelo:
1) Objetos que existen en mi modelo que no existen en el dominio que quiero modelar
(la realidad)
2) Objetos de mi dominio que no aparecen en mi modelo
3) Objeto del dominio que es representado/desglosados en varios en mi dominio
(Complejidad).
4) Varios objetos del dominio representado por un único objeto en mi modelo (Pérdida
de conocimiento)
Buen Modelo:
1) Biyección: 1 a 1 entre objeto del dominio y de mi modelo.
2) Cohesión: Objetos con una única respnsabilidad.

Reglas para nombrar objetos

1. Nombrar objetos a partir del rol que cumplen desde el punto de vista de quién lo
nombran
2. No nombrar vaiables en base al tipo de variable que son. EJ: aArray, aString.

“No alcanza con el nombre para saber qué representa un objeto sino que también los
mensajes que sabe responder”

Paradigma de objetos
Todo es un objeto. No existe diferencia entre funciones, estructuras, etc.

Se divide en dos corrientes:

1) Clásica-Aristotélica Existen dos entes: concretos (ej: una Silla) e ideas (ej: la Silla)
- Clases: Objetos que representan conceptos o ideas del dominio del
problema.
- Instancias/Objetos: Representan lo concreto del dominio del problema.
- Meta-modelo: Modelo que permite hablar de modelos. Todas las clases
derivan de “Class” y “Class” deriva de sí misma.

2) Moderna-Wittgensteniana: Son todos objetos, no existen clases. Son prototipos, es

decir, solo existe la delegación. No existe la diferencia entra instancia y clase. Ej:
Javascript, Self.
- Son más útiles cuando desconozco el dominio del problema. No me
obligan a clasificar cosas que aún no estoy seguro.

Programa
Conjunto de objetos que colaboran enviando mensajes.

Complejidad
Esencial + Accidental → La esencial es propia del dominio de la realidad y no la puedo
reducir. La accidental es la que depende de las herramientas que uso para modelar el
dominio ej: lenguajes de programación, estructuras
Objeto
Representación esencial de un ente del dominio del problema. A partir de los mensajes se
determina el comportamiento del objeto.
- Mensaje: Qué del objeto (Los mensajes se envían)
- Método: Objeto que representa el Cómo de un objeto. Implementación del mensaje,
del Qué. (Los métodos se ejecutan)

“No se dice que se llaman a métodos, sino que se dice que se le envía un mensaje a un
objeto”

Colaboración
Intercambio de mensajes entre objetos.

Emisor --------- mensaje ------→ Receptor

←------ ^retorno ---------

Lenguajes estáticamente tipados vs dinámicamente tipados

Strong: El compilador se fija en tiempo de compilación la mayoría de los tipos de las
variables y muestra errores, por ejemplo en casteos. ej: Java, C#
Weak: El compilador tira warnings en lugar de errores, y casteando solucionás el warning
pero en tiempo de ejecución explota. ej: Python, Smalltalk

ej: Integer i
String s = (String) i
→ Esto en Java se rompe en tiempo de compilación y en C en
tiempo de ejecución.

Soluciones a problemas recurrentes

Idioms: Soluciones concretas a problemas dependiente del lenguaje y no relacionados al
dominio del problema.
Design Patterns: Soluciones abstractas a problemas independientes del lenguaje y no
están relacionados al dominio de problema.
Frameworks: Soluciones concretas dependientes del lenguaje y relacionados al dominio
del problema. (Tienen que tener inversión de control para ser framework, es decir, que los
frameworks son los que envían los mensajes a mis objetos. Código que yo puedo utilizar
para hacer algo.)

Diseño de Modelos
1) Preguntarse por la esencia del objeto (aquella cosa que le saco y el objeto deja de
ser lo que era).
2) Modelar entes de la realidad por el rol que cumplen.
3) IDIOM REPEATED CODE. Cuando tenemos código repetido es que nos está
faltando una abstracción, es decir, una clase/objeto que lo represente. (Código
repetido es distinto a Texto repetido. Código repetido es comportamiento repetido)
- Pasos para sacar código repetido:
1. Copiar el código repetido a un lugar
2. Parametrizar lo que cambia
3. PONERLE NOMBRE
4) Empezar por diagrama de secuencias. Colaboraciones entre objetos (ordenadas en
el tiempo).
a) Escribir solamente el Qué, no el Cómo.
b) Escribir código bién declarativo. No inventar palabras, usar las que usa el
Product Owner, a menos que las palabras sean del dominio sean ambiguas y
sea necesario desambiguarlas.
c) No escribir ciclos (while, for) ni If else.
d) Tratar de no nombrar a los objetos a partir de lo que yo veo, sino del rol
que cumple. ej: LuzRojo del Semáforo debería ser SeñalStop.
5) En el dominio de la realidad se usa el lenguaje natural (ej: factura de un mes) y hay
que saber traspolar eso a lenguaje formal al momento de armar el modelo (ej:
factura de un mes y año)
6) Asignar responsabilidades a un objeto que no debería tener genera acoplamiento
con otros objetos, es decir, conocer implementaciones de otras clases que no
debería conocer.
7) Definir objetos inmutables lo màs que se pueda para ayudar a simplificar el
problema.
8) Crear objetos completos
9) Crear objetos válidos. En el constructor/inicialización (__init__ en py) debería estar
todas las inicializaciones que dejan válido al objeto para usarse.
10) No usar null.
a) Ver el Null Object Pattern. Clase Padre: Address, Clase Hija: NullAddress,
Clase Hija: ExistingAddress.
b) A veces no necesito un objeto null por ejemplo con los strings donde el string
vacío representa el null.
c) En lenguajes statíticamente tipados se usa también “maybe/optional”.
d) Usar una función que si es null ejecute un closure/lambda que se le pasa por
parámetro. EJ: getAddress() en la clase Address sería,
getAddressIfNull(closure).
e) Try/Catch o IF(objet.isNotNull()) no es buen consejo porque implica
acordarse de que puede ser nulo y hay que ponerlo en todos lados.
11) Antropomorfirmo. Asignarle la responsabilidad de “manager” propios a objetos
modelados de la realidad. EJ: objeto registroDeLlamadas sabe buscar una llamada
en su registro en lugar de tenér un objeto buscadorDeLlamadas.
12) Eliminación de IF-ELSE:
a) Cuándo:
- DUDOSO: Si los objetos que colaboran en la condición del IF no
pertenecen al dominio del problema entonces es DUDOSO si sacar o
no el IF.
 - Ejemplo NO: el objeto TicTacToe le manda el mensaje de si
es mayor que 2 a u número que se llama “Coordenada X”. Los
números no son del mismo dominio del problema que
TicTacToe, entonces NO hay que sacar el IF. El número no
tiene por qué saber que debe ser mayor que 2 en ese IF para
que sea True.
- Ejemplo SI: En el IF de TicTacToe estamos preguntando la
diferencia entre la longitud de dos listas con las positions X e
O de TicTacToe, entonces acá SI hay que sacarlo. Se usa el
patrón STATE.
b) Polimorfirmo con Doble Dispatch Pattern. Una clase por cada condición y
un mismo método para los dos cuerpos de las las condiciones. A veces ya
existen las clases EJ: Fracción y Enteros y su interacción. Ver
PortfolioTreePrinter exercise del curso dos.
c) IF(NULL)-ELSE: Se puede evitar usando estados (una nueva clase) por cada
condición State Pattern. El state NUNCA HACE sino que decide QUE
HACER. EJ: StackEmpty y StackIsEmpty de la clase padre StackState y que
se usan en una variable estado de la clase Stack.
d) IF(NULL)-ELSE: Aprovechando el patrón de Object Recursion Pattern.
Separando entre una clase Base y otra Normal. EJ: StackBase y
PushedStack de la clase StackElement
13) Excepciones:
Solo crear nuevas clases de excepciones cuando la intención del sistema es ser
usado por otro sistema. Tratar siempre al principio de no crear ninguna nueva clase
de excepción. EJEMPLO: Haciedo un tictactoe con levantar una RuntimeError con
mensaje de “posición ocupada” es suficiente.
14) Tests de Excepciones:
Siempre verificar no solo que se levanta la excepción esperada sino que no ocurrió
lo que la excepción evitaba que ocurra.
15) Patrones:
a) No usar SINGLETON porque generan acoplamiento global y ocupan la
memoria OLD que usan los garbage collector que corre un algoritmo pesado
que volverìa más lento correcto. Si no uso SINGLETON, los objetos se
borran y crean rápido estando en la memoria NEW sin pasar a la OLD en
donde la NEW se corre un algoritmo rápido.

Polimorfirmo
Relación entre conjunto de objetos y mensajes cuando el conjunto de objetos sabe
responder los mensajes del otro conjunto semánticamente igual, es decir, el Qué (nombre
del mensaje, parámetros y lo que retorna).

“La gran mayoría de los IF pueden reemplazarse por polimorfismo” (ya que los IF se
basan en polimorfismo en su concepción). No conviene remplazar IF por polimofirmo
cuando los objetos que colaboran en la condición del IF no son del mismo dominio del
problema. Cada condicion y cada cuerpo de IF va a ser una abstracción. La condición sería
una clase si es que no existe previamente (en general existe) y el cuerpo va a ser un
método. La idea es que se invierte el orden de quién le manda al mensaje a quién, es decir,
si recibo un objeto que es de cierto tipo y quiero ejecutar cierta lógica, entonces esa lógica
debería estar en ese objeto y yo mandarle el mensaje al objeto de que la ejecute en lugar
de yo implementar la lógica en el objeto incorrecto. (ver Patrón de diseño Doble Dispatch
Pattern)

Super
Super y Self referencian al mismo objeto pero cambian a partir de qué clase se empieza a
buscar la implementación de un método. La búsqueda en Self se da a partir del método que
la implementa y en Super se da a partir de la superclase del método que la implementa.