¿Vale la pena el patrón de objeto nulo?

Question

Estaba mirando el patrón de objeto nulo y me pregunto si vale la pena implementarlo o usar "si" busca nulos en mi código intsead. Cuando miré las implementaciones, parece difícil mantener los objetos bien sincronizados con sus implementaciones nulas. Al realizar cambios en el objeto principal, debemos verificar que el objeto nulo se comporte como se espera y que sea fácil realizar errores de implementación. ¿No es así?

EDITAR

Evitar la comprobación de nulo: http://www.invisible-city.com/sharon/2009/03/null-object-pattern-when-slacker-is.html o http://journalofasoftwaredev.wordpress.com/2008/08/19/null-object-pattern-by-example/

Answer 1

Desde mi experiencia, no creo que sea difícil mantener un objeto nulo sincronizado. Si tiene este problema, su objeto puede tener demasiadas responsabilidades, ya que está sujeto a muchos cambios.

Tiendo a utilizar este patrón si realmente puedo definir dicho objeto en términos de permitir que un comportamiento predeterminado fluya bien. P.ej. Un objeto nulo para una manipulación de consultas es el que deja intacta la consulta original. Una extensión nula a algún otro objeto es una que no hace nada.

A veces me parece un patrón bastante limpio para evitar comprobar si hay un comportamiento opcional que puede existir o no en cierto estado de mi aplicación.

Answer 2

Si su objeto es nulo va a ser una norma en todo el código, usted puede ser que también utilice el patrón. Compruebo nulo cuando un objeto no se ha creado y necesita una instancia. Realmente no uso nulo para nada más, y ciertamente no lo uso para indicar ningún comportamiento definido.

Sin embargo, si está utilizando null para indicar que el comportamiento no se ha definido aún o que el comportamiento predeterminado no es nada, entonces utilice el patrón.

Answer 3

Me aseguro de que mis artículos IEnumerable son enumeraciones vacías en lugar de null, pero si algo falta, ¿qué pasa con null? De vez en cuando necesito distinguir entre sin inicializar y faltando en una situación de inicialización lenta, pero normalmente utilizo una variable booleana para indicar el estado, por lo que cualquier valor (incluido null) es válido para el propio objeto de destino.

Answer 4

He tenido un gran éxito utilizando objetos nulos con mis fábricas y las implementaciones de IoC. Son especialmente útiles para las características verticales de una aplicación. No crearía uno para una acción que sea esencial para su aplicación.

Por ejemplo, tiene una interfaz IPrinter y un par de objetos que la implementan: PrinterX y NullPrinter. En la inicialización de IPrinter, puede intentar iniciar PrinterX, pero si falla, devuelve una NullPrinter en su lugar. En este caso, la impresión es una característica de la aplicación, pero no un requisito para que se ejecute correctamente.

Answer 5

Hay una gran cantidad de ideas erróneas sobre el patrón de diseño NULL que ayuda a evitar las comprobaciones NULL. En realidad, los beneficios del subproducto del patrón de diseño de objetos NULL es que no necesita hacer NULL checl. Pero los controles NULL son buenos y necesarios. El patrón de diseño NULL llena la ausencia de objeto y se debe usar cuando los objetos colaboran con cada uno.

leer este artículo que habla de patrón de diseño de objeto nulo en detalle

http://www.codeproject.com/Articles/1042674/NULL-Object-Design-Pattern

Algunas notas sobre el patrón de diseño NULL que eliminaría la confusión acerca de este patrón.

1. El patrón de diseño NULL llena una AUSENCIA de un objeto con un comportamiento PREDETERMINADO y debe usarse solo cuando un objeto colabora con otro.
2. El patrón de diseño NULL no reemplaza el manejo de excepciones NULL. Es uno de los beneficios secundarios del patrón de diseño NULL pero la intención es proporcionar un comportamiento predeterminado.
3. Las comprobaciones NULL no deben reemplazarse con objetos de patrón de diseño NULO, ya que pueden provocar defectos silenciosos en la aplicación.
   4. El patrón de diseño NULL es útil en la prueba de unidades falsas y el desarrollo ágil.
   5. Las clases NULL son un caso clásico para aplicar el patrón de diseño de Singleton y hacer que las clases sean inmutables.

Este patrón se observa sobre todo en combinación con decorador y fábrica de patrón.