É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.

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Una breve introducción a la teoría del cerebro de Boltzmann

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

El modelo Bitcoin UTXO, impulsando un ecosistema único

Una breve introducción a la teoría del cerebro de Boltzmann

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps