Evitando la violación del Principio de abstracción reutilizada

Question

En Dependency Injection, programamos en contra de una abstracción.

Desde mi experiencia, puedo afirmar que la mayoría de las abstracciones en una aplicación tienen una relación 1: 1 con sus implementaciones. Esto es una violación de Reused Abstraction Principle.

Marcos Seeman sugerido en algunos de sus mensajes que podemos tener una implementación de objeto nulo para las abstracciones con el fin de evitar RAP violación (Esta sugerencia de Mark Seeman podría ser mi inferencia. Por favor me corrija si estoy equivocado cita a Mark en esto). Mi pregunta aquí es

1. ¿Cómo hacer la implementación de objetos nulos?
2. ¿Está bien violar RAP?

Answer 1

Personalmente me resulta útil para programar a una abstracción, incluso si no es sólo una aplicación de producción. En particular:

• Incluso si sólo tienen una producción aplicación, que bien puede tener otras implementaciones en pruebas, ya sea falsificaciones en toda regla o se burla creados dinámicamente
• Es una expresión más clara de las dependencias que dependiendo de la clase concreta en muchos casos. Por ejemplo, la clase concreta puede exponer a otros miembros públicos de los que no depende , por varias razones.

Eso sí, esta es una afirmación falsa para comenzar con:

En la inyección de dependencias que programar contra una abstracción.

Puede usar la inyección de dependencia con clases de hormigón con total facilidad. No hay nada que decir que tiene para crear interfaces para sus dependencias. La inyección de dependencia se refiere más a cómo obtiene su clase sus dependencias que a qué nivel de abstracción utiliza para expresarlas.

Así que, básicamente:

• no hay que subestimar la importancia de "dobles" de prueba para implementar abstracciones, incluso si sólo tiene una implementación de producción
• No tenga miedo a depender de la aplicación concreta si realmente lo desea, pero inyectar esa dependencia es aún más limpio que crearla dentro de su clase, donde realmente es una dependencia "propia"
• No intente inyectar todo si el comportamiento de la dependencia no es ' t realmente un en teracción entonces puede que no desee inyectarlo. Por ejemplo, no comience a inyectar "proveedores de colecciones" solo para evitar crear instancias de List<T>; no necesita aislar su clase del comportamiento de List<T> para propósitos de prueba, por ejemplo.