¡Perdónenme por el pseudo código con anticipación!
Lectura en principios SOLIDOS. Hay algunos motivos en los principios SOLID para usar interfaces. Las interfaces le permiten desacoplar sus dependencias en la implementación. Puede llevar esto un paso más allá al usar una herramienta como StructureMap para realmente hacer que el acoplamiento se derrita.
en la que podría ser utilizado para
Widget widget1 = new Widget;
Esto dice específicamente que desea crear una nueva instancia de widget. Sin embargo, si hace esto dentro de un método de otro objeto, ahora está diciendo que el otro objeto depende directamente del uso de Widget.Entonces podríamos decir algo como
public class AnotherObject
{
public void SomeMethod(Widget widget1)
{
//..do something with widget1
}
}
Todavía estamos vinculados al uso de Widget aquí. Pero al menos esto es más comprobable ya que podemos inyectar la implementación de Widget en SomeMethod. Ahora bien, si tuviéramos que usar una interfaz en su lugar, podríamos desacoplar aún más las cosas.
public class AnotherObject
{
public void SomeMethod(IWidget widget1)
{
//..do something with widget1
}
}
en cuenta que estamos ahora que no requieren una implementación específica de Widget sino que estamos pidiendo nada que se ajuste a iwidget interfaz. Esto significa que cualquier cosa podría ser inyectada, lo que significa que en el uso diario del código podríamos inyectar una implementación real de Widget. Pero esto también significa que cuando queremos probar este código, podemos inyectar un falso/simulacro/stub (dependiendo de su comprensión de estos términos) y probar nuestro código.
Pero, ¿cómo podemos llevar esto más allá. Con el uso de StructureMap podemos desacoplar este código aún más. Con el último ejemplo de código de nuestro código de llamada mi mirada algo como esto
public class AnotherObject
{
public void SomeMethod(IWidget widget1)
{
//..do something with widget1
}
}
public class CallingObject
{
public void AnotherMethod()
{
IWidget widget1 = new Widget();
new AnotherObject().SomeMethod(widget1);
}
}
Como se puede ver en el código anterior hemos eliminado la dependencia en el SomeMethod mediante introducción de un objeto que se ajusta a iwidget. Pero en CallingObject(). AnotherMethod todavía tenemos la dependencia. ¡También podemos utilizar StructureMap para eliminar esta dependencia!
[PluginFamily("Default")]
public interface IAnotherObject
{
...
}
[PluginFamily("Default")]
public interface ICallingObject
{
...
}
[Pluggable("Default")]
public class AnotherObject : IAnotherObject
{
private IWidget _widget;
public AnotherObject(IWidget widget)
{
_widget = widget;
}
public void SomeMethod()
{
//..do something with _widget
}
}
[Pluggable("Default")]
public class CallingObject : ICallingObject
{
public void AnotherMethod()
{
ObjectFactory.GetInstance<IAnotherObject>().SomeMethod();
}
}
Observe que en ningún lugar del código anterior estamos instantando una implementación real de AnotherObject. Como todo está cableado para StructurMap, podemos permitir que StructureMap pase en las implementaciones apropiadas dependiendo de cuándo y dónde se ejecuta el código. Ahora el código es verdaderamente flexible ya que podemos especificar a través de la configuración o programáticamente en una prueba qué implementación queremos usar. Esta configuración se puede realizar sobre la marcha o como parte de un proceso de compilación, etc. Pero no tiene que estar cableada en ninguna parte.
No entiendo el argumento en contra de ... –
si necesita explicarle a su equipo por qué las interfaces son un buen estándar de programación, entonces debe encontrar un nuevo trabajo ... sin ofensa ... –
Acepto la búsqueda de un nuevo comentario de trabajo. – Finglas