Per favore perdonami per lo pseudo codice in anticipo!
Leggere i principi SOLID. Ci sono alcuni motivi nei principi SOLID per l'utilizzo delle interfacce. Le interfacce consentono di disaccoppiare le dipendenze dall'implementazione. Puoi fare un ulteriore passo avanti usando uno strumento come StructureMap per far sciogliere l'accoppiamento.
Dove si potrebbe essere utilizzato per
Widget widget1 = new Widget;
Questo dice specificamente che si desidera creare una nuova istanza di Widget. Tuttavia, se lo fai all'interno di un metodo di un altro oggetto, stai dicendo che l'altro oggetto dipende direttamente dall'uso del Widget.Quindi potremmo quindi dire qualcosa come
public class AnotherObject
{
public void SomeMethod(Widget widget1)
{
//..do something with widget1
}
}
Siamo ancora legati all'uso di Widget qui. Ma almeno questo è più testabile in quanto possiamo iniettare l'implementazione di Widget in SomeMethod. Ora, se dovessimo utilizzare un'interfaccia, potremmo ulteriormente disaccoppiare le cose.
public class AnotherObject
{
public void SomeMethod(IWidget widget1)
{
//..do something with widget1
}
}
Si noti che stiamo ora non richiedere una specifica implementazione di widget, ma invece stiamo chiedendo per tutto ciò che è conforme alla iWidget interfaccia. Ciò significa che qualsiasi cosa potrebbe essere iniettata, il che significa che nell'uso quotidiano del codice potremmo iniettare una reale implementazione del Widget. Ma questo significa anche che quando vogliamo testare questo codice possiamo iniettare un falso/mock/stub (dipende dalla tua comprensione di questi termini) e testare il nostro codice.
Ma come possiamo continuare. Con l'uso di StructureMap possiamo disaccoppiare questo codice ancora di più. Con l'ultimo esempio di codice il nostro codice chiamante il mio aspetto qualcosa di simile
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);
}
}
Come si può vedere nel codice sopra abbiamo rimosso la dipendenza nel SomeMethod passando in un oggetto che è conforme alla iWidget. Ma nel CallingObject(). AnotherMethod abbiamo ancora la dipendenza. Possiamo usare StructureMap per rimuovere anche questa dipendenza!
[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();
}
}
Si noti che non ci sono dove nel codice precedente stiamo istanziando un'implementazione effettiva di AnotherObject. Poiché tutto è cablato per StructurMap, possiamo consentire a StructureMap di passare nelle implementazioni appropriate a seconda di quando e dove viene eseguito il codice. Ora il codice è davvero flessibile in quanto possiamo specificare tramite configurazione o in modo programmatico in un test l'implementazione che vogliamo utilizzare. Questa configurazione può essere eseguita al volo o come parte di un processo di compilazione, ecc. Ma non deve essere cablata ovunque.
Non capisco l'argomento contro ... –
se hai bisogno di spiegare al tuo team perché le interfacce sono un buon standard di programmazione, allora dovresti trovare un nuovo lavoro..no offesa .. –
Sono d'accordo con la ricerca nuovo commento di lavoro. – Finglas