Necesidad de interfaces, inyecciones en proyecto único.

Question

¿Por qué debería implementar Interfaces y la inyección de dependencia en un sitio sin casi ninguna posibilidad de reutilización o actualización por parte de otra persona?

Answer 1

Cuando aprendiste a programar una computadora, estabas desarrollando una especie de "memoria muscular" de tu oficio. A lo largo de los años, continúas programando en esa misma mentalidad. La mayoría de las personas no aprenden todos los principios ingeniosos de la POO desde el principio, por lo que parece que son más un esfuerzo que la forma en que aprendieron.

Debes acostumbrarte a utilizar técnicas de diseño OOP siempre que estés usando un lenguaje OOP, porque eso te hará un mejor desarrollador en general. Tu objetivo debe ser volver a entrenar tu memoria muscular de la programación para usar esas técnicas. Entonces, no tendrá que hacer estas preguntas y asumir que las técnicas están de alguna manera 'estorbando' su programación. Te conviertes en un programador que simplemente programa de esa manera.

Answer 2

A menudo hace que las pruebas unitarias sean un poco más simples. Por ejemplo, puede tener un tipo que usa otro tipo que se conecta a una base de datos. Para la prueba unitaria del primer tipo, puede inyectar una prueba simulada en lugar del segundo tipo, lo que le permite realizar una prueba unitaria del primer tipo sin conectarse indirectamente a la base de datos a través del segundo tipo.

Answer 3

¿Por qué, efectivamente?

No creo que las interfaces y la inyección sean solo sobre la reutilización o la actualización.

Personalmente, uso interfaces y DI para todos los proyectos. No es suficiente una sobrecarga para hacer que evitarlos sea un beneficio.

Answer 4

Porque la suposición de que está haciendo es la misma que dio como resultado Y2K.

Answer 5

Encuentro que hace que sea mucho más fácil reutilizar mi código en formas que aún no he pensado. También hace que sea más fácil cambiar cómo funciona el código sin cambiar el código fuente.

Estoy usando Spring.NET para la inyección de dependencia.

Supongamos que tiene una clase de máquina que tiene una función DoWork (). Luego creas una interfaz IWorkAlgorithm, con implementaciones de algoritmos específicos para cada máquina.

Cada instancia de Machine tiene un IWorkAlgorithm inyectado en él, y Machine.DoWork () llama a la implementación inyectada.

Ahora tienes las siguientes ventajas:

1. Puede intercambiar nuevas implementaciones simplemente editando un archivo XML.
2. Puede cambiar las propiedades de cada implementación (tiempos de espera, límites, etc.) editando un archivo XML.
3. Puede reutilizar sus implementaciones fuera de la clase Máquina.

Answer 6

Si estás haciendo programación orientada a objetos, incluso si eres el único desarrollador que verá el código, deberías seguir haciendo pruebas de unidad, y eso se complica si no utilizas la inyección de dependencia.

No olvides que el " otro desarrollador " en su software puede muy bien ser usted. Puede piratear una masa de código inter-dependiente altamente acoplado que funciona, e incluso entenderlo mientras está trabajando en él, pero en el momento en que se aleje del proyecto, incluso por un par de días, comenzará. olvidarse de todas las pequeñas cosas que impidieron que la bola de hilo se deshiciera.

Cuando vuelva a él (y aún no he visto un software que no requirió algunos cambios más adelante), deseará haber seguido todas las mejores prácticas.