Él no es nuestro amigo. No simplifica la vida ni nos hace más eficientes. Sólo más perezoso. Es hora de dejar de usar . null Derribando otra inveteracy Todos nosotros hemos estado usando mucho null. Es cómodo, es eficiente, es rápido y, sin embargo, hemos sufrido un montón de problemas relacionados con su uso. ¿Cuál es el sesgo cognitivo que actualmente nos impide, además de reconocer el problema, empezar a solucionarlo? ¿Qué significa nulo? es una bandera. Representa diferentes situaciones según el contexto en el que se utilice e invoque. Nulo Esto arroja el error más grave en el desarrollo de software: acoplar una decisión oculta en el contrato entre un objeto y quien lo usa . Acoplamiento: el único problema de diseño de software Por si esto fuera poco, rompe la biyección que era nuestra . . única regla de diseño Representando múltiples elementos del dominio con la misma entidad y obligando a tener interpretaciones contextuales El único principio de diseño de software Un buen principio de software nos desafía a tener una alta cohesión. Todos los objetos deben ser lo más específicos posible y tener una sola responsabilidad (La S de ). Sólido El objeto menos cohesivo de cualquier sistema es nuestro comodín: nulo Nulo se asigna a varios conceptos diferentes en el mundo real fallas catastróficas no es polimórfico con ningún objeto, por lo que cualquier función que lo invoque romperá la cadena de llamadas posteriores. Null Ejemplo 1: Modelemos la interacción entre personas durante la pandemia actual de covid-19. { { ( ->meetingProbability() < random()) { ; } { PersonToPersonInteraction($somePerson, $anotherPerson); } } } { { ( ->somePerson->isInfectedWith($aVirus) && $aVirus->infectionProbability() > random()) { ->anotherPerson->getInfectedWith($aVirus); } } } $covid19 = Virus(); $janeDoe = Person(); $johnSmith = Person(); $wuhan = City(); $interaction = $wuhan->interactionBetween($johnSmith, $janeDoe); ($interaction != ) { $interaction->propagate($covid19); } final class City public function interactionBetween ($somePerson, $anotherPerson) if $this return null //no interaction else return new final class PersonToPersonInteraction public function propagate ($aVirus) if $this $this new new new new if null /* In this example we modeled the interaction between an infected person and a healthy one. Jane is healthy but might be infected if Virus R0 applies to her.*/ Podemos ver que hay dos banderas y las cláusulas correspondientes. nulas if La propagación nula parece estar contenida, pero las apariencias engañan. Un poquito de historia La creación de ocurrió debido a un evento fortuito en 1965. null : El creador del algoritmo QuickSort y también ganador del Premio Turing (el Premio Nobel de Computación) lo agregó al lenguaje porque parecía práctico y fácil de hacer. Varias décadas después mostró su arrepentimiento: Tony Hoare Algol Este excelente artículo cuenta la historia en detalle: Referencias de puntero nulo: el error del billón de dólares Yo lo llamo mi error de mil millones de dólares... En ese momento, estaba diseñando el primer sistema completo de tipos para referencias en un lenguaje orientado a objetos. Mi objetivo era garantizar que todos los usos de las referencias fueran absolutamente seguros, con la verificación realizada automáticamente por el compilador. Pero no pude resistir la tentación de poner una referencia nula, simplemente porque era muy fácil de implementar. Esto ha llevado a innumerables errores, vulnerabilidades y bloqueos del sistema, que probablemente han causado mil millones de dólares en dolor y daños en los últimos cuarenta años. – Tony Hoare, inventor de ALGOL W. El video completo también está disponible . aquí La excusa Nosotros, como desarrolladores, usamos porque es fácil (de escribir) y porque creemos que mejora la eficiencia de nuestro software. nulo Al cometer este error ignoramos que el código se lee hasta . 10 veces más de lo que se escribe Leer código con es más arduo y difícil. Por lo tanto, solo posponemos el problema más adelante. nulos Respecto a la eficiencia (que es la excusa más utilizada para ). Salvo en casos muy concretos y críticos, su pérdida de rendimiento es despreciable. Y solo se justifica en aquellos sistemas que priorizan la eficiencia sobre la legibilidad, la adaptabilidad y la mantenibilidad (siempre hay una compensación con respecto a los atributos de calidad). generar acoplamiento Este sesgo cognitivo persistió en el tiempo aunque, según el actual Las máquinas virtuales modernas y de última generación optimizan el código para nosotros. Para usar evidencia en lugar de intuición, solo necesitamos comenzar a comparar en su lugar de seguir afirmando erróneamente que la eficiencia es más importante que legibilidad. Fallar rapido se (ab)utiliza para enmascarar situaciones inesperadas y propagar el error en el código demasiado lejos, generando el tan temido efecto dominó. Null Uno de los principios del buen diseño es fallar rápido. Ejemplo 2: Dado un formulario de entrada de datos para un paciente, se nos solicita que completemos la fecha de nacimiento. Si hay un error en el componente visual y la creación del objeto, podría construirse con una fecha de nacimiento . nula Al ejecutar un proceso por lotes nocturno que recopila todas las fechas de la pacientes para calcular una edad promedio, el paciente ingresado generará un error. La pila con información útil para el desarrollador estará muy lejos de donde está presente el defecto. ¡Feliz depuración! Photo by Victoria Heath on Unsplash Además, pueden existir diferentes sistemas con diferentes lenguajes de programación, transmisión de datos a través de una API, archivos, etc. La peor pesadilla del desarrollador es tener que depurar ese error temprano en la mañana y tratar de encontrar la causa raíz del problema. Objetos incompletos se usa de muchas maneras, como mencionamos anteriormente. Si permitimos modelos incompletos, la falta de integridad generalmente se modela con un . Esto agrega complejidad al completar el código de controles con ifs. Null valor nulo La presencia de nulos genera y desordena el código con múltiples controles . código repetitivo ifs Fomentar modelos incompletos nos obliga a cometer dos errores adicionales: 1. Contaminar código con para completar la información esencial necesaria. setters Modelos Desnudos - Parte I: Setters 2. Construir modelos violando la ignorando que las entidades su esencia. mutables biyección del mundo real no mutan en ¿Es muy claro para todos que una fecha no debe mutar? Idiomas escritos que no manejan opcionalmente La mayoría de los lenguajes escritos evitan errores al garantizar que el objeto que se envía como parámetro (o se devuelve) puede responder a un determinado protocolo. Desafortunadamente, algunos de estos lenguajes han dado un paso atrás de permitiendo declarar que el objeto es de cierto tipo y (opcionalmente) . nulo Esto rompe la cadena de invocaciones obligando a a controlar la ausencia del objeto violando el . Ifs principio Sólido abierto/cerrado Además, los controles de tipo corrompen. Si usamos un lenguaje escrito y confiamos en la red de defensa del compilador. logra penetrarlo como un virus y propagarse a los otros tipos como se indica a continuación. nulo Null El peor error de la informática - Lucidchart La solución No lo uses. las alternativas Como siempre, para resolver todos nuestros problemas debemos permanecer fieles a la única regla de diseño axiomática que nos hemos impuesto. Busque soluciones en el dominio del problema para traerlas a nuestro modelo. Modelar ausencias polimórficas En el caso anterior, cuando los objetos deben declarar un tipo, existen soluciones más elegantes que evitan que los opcionalmente. ifs modelen En los lenguajes de clasificación, basta con utilizar el patrón de en nuestra clase hermana concreta y declarar el supertipo como un tipo del colaborador basado en el (L de SOLID). diseño NullObject principio de sustitución de Liskov Sin embargo, si decidimos implementar esa solución, estaremos violando otro principio de diseño que establece: Deberíamos subclasificar por razones esenciales y no para reutilizar código o ajustar jerarquías de clases. La mejor solución en un lenguaje de clasificación es declarar una interfaz a la que deben adherirse tanto la como la . clase real clase de objeto nulo En el primer ejemplo: { ; } { { } } { { ( ->somePerson->isInfectedWith($aVirus) && $aVirus->infectionProbability() > random()) { ->anotherPerson->getInfectedWith($aVirus); } } } { { SocialDistancing(); } } $covid19 = Virus(); $janeDoe = Person(); $johnSmith = Person(); $wuhan = City(); $interaction = $wuhan->interactionBetween($johnSmith, $janeDoe); $interaction->propagate($covid19); Interface SocialInteraction public function propagate ($aVirus) final class SocialDistancing implements SocialInteraction public function propagate ($aVirus) //Do nothing !!!! final class PersonToPersonInteraction implements SocialInteraction public function propagate ($aVirus) if $this $this final class City public function interactionBetween ($aPerson, $anotherPerson) return new // The cities are smart enough to implement social distancing to model Person to Person interactions new new new new /* Jane will not be affected since the interaction prevents from propagating the virus ¡No hay virus involucrados ni ifs ni nulls! En este ejemplo, reemplazamos con una especialización que, a diferencia de ella, existe en el dominio del problema. nulo Fecha de nacimiento del paciente revisada Volvamos al ejemplo del formulario del paciente. Necesitábamos calcular el promedio dejando fuera los formularios no llenados. { ; } { { $aVisitor->visitDate( ); } } { { $aVisitor->visitDateNotPresent( ); } } { $count = ; $ageSum = ; { ->count++; ->ageSum += today() - $aDate; } { } { ( ->count == ) ; ->ageSum / ->count; } } { $calculator = AverageCalculator(); ($patients $patient) $patient->birthDate()->accept($calculator); $calculator->average(); } Interface Visitable public function accept ($aVisitor) final class Date implements Visitable public function accept ($aVisitor) $this final class DateNotPresent implements Visitable public function accept ($aVisitor) $this final class AverageCalculator private 0 private 0 public function visitDate ($aDate) $this $this public function visitDateNotPresent ($aDate) public function average () if $this 0 return 0 else return $this $this function averagePatientsAge ($patients) new foreach as return Usamos el para navegar por objetos que pueden comportarse como objetos nulos. patrón Visitor sin valores nulos Además, eliminamos lo usamos polimorfismo y dejamos la solución abierta a a través del principio abierto/cerrado. no esencial si otros cálculos además del promedio Construimos una solución menos algorítmica pero más declarativa, mantenible y extensible. Usar lenguajes con modelado explícito de ausencias Algunos idiomas admiten opcionalmente con el concepto de Maybe/Optional que es un caso particular de la solución propuesta implementada anteriormente a nivel de idioma. Conclusiones El uso de es una práctica desaconsejada basada en prácticas profundamente arraigadas en nuestro industria. A pesar de esto, casi todos los lenguajes comerciales lo permiten y los desarrolladores lo utilizan. null Deberíamos, al menos, empezar a cuestionar su uso y ser y responsables en el desarrollo de software. más maduros Parte del objetivo de esta serie de artículos es generar espacios de debate y discusión sobre el diseño de software. Esperamos comentarios y sugerencias sobre este artículo. Este artículo también está disponible en español y en chino . aquí aquí

Chain

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

HackerNoon Mobile

NULL: El error del billón de dólares

Demasiado Largo; Para Leer

Coin Mentioned

@mcsee

HISTORIAS RELACIONADAS