Últimamente he encontrado el patrón de diseño Objeto nulo y mis colegas dicen que se puede utilizar para eliminar las comprobaciones de puntero nulo que se encuentran en todo el código.Patrón de objeto nulo para evitar las comprobaciones nulas?
por ejemplo, supongamos que una clase DAO devuelve información sobre el cliente (en un objeto de valor denominado CustomerVO). Se supone que mi clase principal debe extraer el firstName y el emailId y enviar un correo electrónico al cliente.
...
CustomerVO custVO = CustomerDAO.getCustomer(customerID);
if(custVO != null) { // imp, otherwise we may get null ptr exception in next line
sendEmail(custVO.getFirstName(), custVO.getEmailID());
}
...
Esto es muy simple ejemplo, pero tales cheques nulos pueden propagarse rápidamente a través de su código basado en la complejidad de los objetos de valor.
Tengo dos problemas con el registro de entrada nula, - tienden tmake el código feo y difícil de leer - menos experimentados desarrolladores ponen cheques nulos innecesarios cuando en realidad se supone que lanzar excepciones. por ej. en el código anterior, sería mejor emitir una excepción de getCustomer() en sí mismo porque si no puede encontrar información del cliente para CustID dado, indica que CustID no es válido.
bien, volviendo al patrón de objeto nulo, ¿podemos usar un objeto CustomerVO 'nulo' para ocultar la verificación nula?
CustomerVO {
String firstName = "";
String emailID = "";
}
No tiene sentido. ¿Qué piensas?
Y cuáles son las cosas que debe seguir para minimizar las comprobaciones nulas en su aplicación.
+1, aunque no me gustaría que mis clientes tienen métodos sendEmail.Eso solo le está dando demasiadas responsabilidades a un cliente. Es como dar a cada clase un método de "impresión" y tener que implementar la lógica de impresión en todas partes o hacer que cada clase dependa de un administrador de impresión, mientras que podría restringirse a un administrador de impresión y los formularios/clases que realmente inician la impresión dando al administrador de impresión las clases para imprimir. Donde el patrón nulo es realmente bueno, está en pruebas unitarias, por ejemplo, para proporcionar una clase de registro que no hace nada, por lo que no es necesario modificar el código que se prueba. –