Buenas,
Me está llevando mucho tiempo pensar el trabajo ya desde el hecho de tener que chequear la existencia o no de un string (persona). Y algo similar con los eventos/fechas (en mi diseño).
Entonces mi duda es, juega mucho en contra el uso-casi-abuso de at:ifPresent: (o sus variantes)? Es decir, cuenta como un ifFalse:ifTrue:? O es lo que está bien?
No llego a otra cosa más que diccionarios por todos lados, y estoy convencido que esto se puede resolver sin IFs o cosas extrañas como las que pienso.
Hola Ignacio:
Es muy difícil responder esto de manera contundente porque es algo muy relativo. Depende mucho de tu modelo y de qué posibilidades sacrificás a costa de este tipo de decisiones.
El tema de desalentar el uso de estructuras de control es principalmente para no violar el encapsulamiento pero no significa que nunca haya que usar un if. Por ejemplo, si en la solución ponen algo de este estilo:
(evento esSemanal)
ifTrue: [ " hago algo " ]
ifFalse: [ " hago otra cosa ].
se consideraría como un "error" muy grave porque viola el encapsulamiento de manera explícita, el acoplamiento es muy alto y, por consiguiente, el diseño no es muy orientado a objetos.
Pero fuera de este tipo de casos tan groseros el tema de los ifs pasa a ser más subjetivo. Hay muchas situaciones que no se pueden hacer sin un if y, en muchos casos se pueden refactorizar con otros métodos como mencionás, que hacen que el código sea más prolijo. En casos de algunas validaciones o lanzamientos de excepciones no hay alternativa y nadie te va a poner que está mal el if ahí. Una vez que se determina que el if es inevitable el dilema pasa por quién lo hace, es decir, qué objeto debe tener la responsabilidad de preguntar eso evitando la violación del encapsulamiento.
En muchos casos un diccionario te ayuda bastante para poner el nombre como clave y el objeto como valor, por más que el objeto ya tenga el string guardado como atributo. Es una buena práctica. Otra alternativa es crearte una clase nueva que sirva como capa intermedia contenedora que tenga la responsabilidad de resolver edo pero no siempre vale la pena.
Saludos,
Tomás