¿Por qué el “nuevo” operador se considera perjudicial?

Algunos idiomas y versiones incluyen dulces de sintaxis que reducen la necesidad del operador “nuevo”, pero eso no es necesariamente porque “nuevo” es malo, sino que puede ser detallado. Sin embargo, lo más importante es la abundancia de operadores “nuevos” en un programa, que pueden introducir dependencias cableadas que reducen la flexibilidad y pueden complicar el mantenimiento.

Existen varios patrones de software que reducen la introducción de dependencias cableadas. Por ejemplo, Spring Framework implementa un patrón de software llamado “Inyección de dependencia”, que crea e “inyecta” instancias de objetos (beans) siguiendo la configuración especificada en archivos de configuración separados.

Me atrevería a decir que Rod Johnson, quien fundó el marco Spring, no se despertó una mañana con la misión de matar a todos los ‘nuevos’ operadores que pudo encontrar. La principal preocupación era mejorar la capacidad de mantenimiento y la flexibilidad del software, al reducir las dependencias cableadas. ‘nuevo’ resultó ser uno de los principales vehículos para conectar esas dependencias.

Al final, los objetos ‘nuevos’ todavía se crean todo el tiempo en Spring, pero en la mayoría de los casos eso es controlado por el marco, no por el código de la aplicación.

Creo que DI tiene mucho mérito al proporcionar una mayor flexibilidad y confiabilidad, pero, como todo, también tiene sus costos y puede ser abusado. DI también tiene problemas propios; por ejemplo, el marco introduce una pequeña sobrecarga de ejecución, pero potencialmente significativa.

También he observado que los archivos de configuración que “conectan” las inyecciones de frijoles pueden ser complejos y crecer mucho, lo que los hace potencialmente difíciles de entender y mantener. Además, leer el código puede ser más difícil incluso para un desarrollador Java experimentado que resulta ser nuevo en este tipo de marcos. Cuando se usa Spring, puede que no se vea de inmediato qué beans se están usando o inyectando, ya que puede tener múltiples archivos de configuración, lo que lo hace lidiar con “spaghetti de dependencia”.

Estoy escribiendo C ++ para un procesador integrado. En este entorno nunca uso nuevo.

Con un procesador embebido, uno debe ser consciente de dos limitaciones: ciclos y ram.

Primero, nuevos usos alloc y gratuitos, dos operaciones costosas. En segundo lugar, con el tiempo el montón puede desorganizarse y fragmentarse, por lo que es mejor tener cargas de mierda, incluso si todo lo que necesita es un poco.

Es mejor tener sus objetos declarados estáticos o en la pila. Sabes exactamente cuáles son las demandas.

Si necesita datos variables, por ejemplo, una cola de eventos, es mejor declarar una matriz estática de objetos y administrarla usted mismo. No copie y use aloc / memoria libre en el montón.

Hay un dicho en el diseño orientado a objetos “nuevo es pegamento”. Crear una dependencia dentro de una clase usando nuevas parejas de su clase a una implementación específica de esa dependencia. Es mucho mejor recibir dependencias a través de la inyección del constructor para que su clase solo esté acoplada a una interfaz.

En segundo lugar, las dependencias que se crean usando nuevas dificultan las pruebas, ya que no puede crear una instancia de su clase sin crear esas dependencias con ellas y tener que probarlas juntas, lo cual es una mala práctica de prueba. Inyectarse dependencias significa que puede tropezar o burlarse de esas dependencias en sus pruebas unitarias

Tal vez en c ++ si olvida liberarlo, es mejor usar contenedores inteligentes y punteros inteligentes, ¿pero Java? El gc maneja esas cosas, no debes preocuparte por eso.

Proporcione algunos recursos que lo hagan pensar así. Hasta donde sé, ‘nuevo’ operaror es la única forma de asignar memoria en Java.