A menudo me encuentro con este problema, especialmente en Java, incluso si creo que es un problema general de POO. Es decir: al generar una excepción se revela un problema de diseño.
Supongamos que tengo una clase que tiene un campo String name y un campo String surname .
Luego usa esos campos para componer el nombre completo de una persona para mostrarlo en algún tipo de documento, digamos una factura.
public void String name;
public void String surname;
public String getCompleteName() {return name + " " + surname;}
public void displayCompleteNameOnInvoice() {
String completeName = getCompleteName();
//do something with it....
}
Ahora quiero reforzar el comportamiento de mi clase lanzando un error si se llama a displayCompleteNameOnInvoice antes de que el nombre haya sido asignado. Parece una buena idea, ¿no?
Puedo agregar un código de aumento de excepciones al método getCompleteName .
Pero de esta manera, estoy violando un contrato 'implícito' con el usuario de la clase; en general, los captadores no deben lanzar excepciones si sus valores no están establecidos. Ok, esto no es un captador estándar ya que no devuelve un solo campo, pero desde el punto de vista del usuario, la distinción puede ser demasiado sutil como para pensar en ello.
O puedo lanzar la excepción desde dentro de displayCompleteNameOnInvoice . Pero para hacerlo, debería probar directamente los campos name o surname y al hacerlo violaría la abstracción representada por getCompleteName . Es responsabilidad de este método verificar y crear el nombre completo. Incluso podría decidir, basando la decisión en otros datos, que en algunos casos es suficiente el surname .
Entonces la única posibilidad parece cambiar la semántica del método getCompleteName a composeCompleteName , que sugiere un comportamiento más "activo" y, con ello, la capacidad de lanzar una excepción.
¿Es esta la mejor solución de diseño? Siempre estoy buscando el mejor equilibrio entre simplicidad y corrección. ¿Hay una referencia de diseño para este problema?