Capítulo 71. Refactorizar valores booleanos a enumeraciones
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Peter Hilton
No utilizarías "números mágicos" en tu código, ¡así que tampoco utilices booleanos mágicos! Los literales booleanos son peores que los números codificados: un 42 en el código puede parecer familiar, pero false podría ser cualquier cosa, y cualquier cosa podría ser falsa.
Cuando dos variables son ambas true, no sabes si es una coincidencia o si ambas son "verdaderas" por la misma razón y deben cambiar juntas. Esto hace que el código sea más difícil de leer, y provoca fallos cuando se lee mal. Al igual que con los números mágicos, deberías refactorizar a constantes con nombre.
Refactorizar 42 a una constante ASCII_ASTERISK o EVERYTHING mejora la legibilidad del código, al igual que refactorizar true a una constante booleana llamada AVAILABLE en una clase Product, por ejemplo. Sin embargo, probablemente no deberías tener ningún campo booleano en tu modelo de dominio: algunos valores booleanos no son realmente booleanos.
Supongamos que tu entidad Product tiene un campo booleano available, para indicar si el producto se está vendiendo actualmente. Esto no es realmente un booleano: es un valor opcional "disponible", que no es lo mismo porque "no disponible" significa realmente otra cosa, como "agotado". ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access