Que signifie “programme pour les interfaces, pas implémentations” signifie?

Interfaces sont juste des contrats ou des signatures et ils ne savent pas
rien sur les implémentations.

De codage par rapport à l'interface de moyens, le code client détient toujours un objet de l'Interface qui est fournie par l'usine. Toute instance retournée par l'usine serait de type Interface qui tout en usine candidat classe doit être mis en œuvre. De cette façon, le programme client n'est pas inquiet au sujet de la mise en œuvre et l'interface de signature détermine ce que toutes les opérations peuvent être effectuées. Ceci peut être utilisé pour modifier le comportement d'un programme au moment de l'exécution. Il vous aide également à écrire loin de meilleurs programmes à partir de la maintenance du point de vue.

Voici un exemple de base pour vous.

public enum Language
{
English, German, Spanish
}
public class SpeakerFactory
{
public static ISpeaker CreateSpeaker(Language language)
{
switch (language)
{
case Language.English:
return new EnglishSpeaker();
case Language.German:
return new GermanSpeaker();
case Language.Spanish:
return new SpanishSpeaker();
default:
throw new ApplicationException("No speaker can speak such language");
}
}
}
[STAThread]
static void Main()
{
//This is your client code.
ISpeaker speaker = SpeakerFactory.CreateSpeaker(Language.English);
speaker.Speak();
Console.ReadLine();
}
public interface ISpeaker
{
void Speak();
}
public class EnglishSpeaker : ISpeaker
{
public EnglishSpeaker() { }
#region ISpeaker Members
public void Speak()
{
Console.WriteLine("I speak English.");
}
#endregion
}
public class GermanSpeaker : ISpeaker
{
public GermanSpeaker() { }
#region ISpeaker Members
public void Speak()
{
Console.WriteLine("I speak German.");
}
#endregion
}
public class SpanishSpeaker : ISpeaker
{
public SpanishSpeaker() { }
#region ISpeaker Members
public void Speak()
{
Console.WriteLine("I speak Spanish.");
}
#endregion
}

C'est juste un exemple de base et
véritable explication du principe est
au-delà de la portée de cette réponse.

MODIFIER

J'ai mis à jour l'exemple ci-dessus et ajouté un résumé de haut-Parleur de la classe de base. Dans cette mise à jour, j'ai ajouté une fonction à tous les Spakers à "SayHello". Tous les haut-parleurs de parler de "Hello World". Donc, c'est une caractéristique commune avec des fonctions similaires. Reportez-vous au diagramme de classe et vous verrez que le haut-Parleur classe abstraite mettre en œuvre ISpeaker interface et les marques de la Parole() abstraite, ce qui signifie que chaque haut-Parleur de la mise en œuvre est responsable de la mise en œuvre de la méthode Parler, car il varie d'un haut-Parleur de haut-Parleur. Mais tous les haut-parleurs de dire "Bonjour" à l'unanimité. Donc, dans l'abstrait, haut-Parleur de la classe, nous définissons une méthode qui dit "Hello World" et chaque haut-Parleur de la mise en œuvre va dériver la méthode SayHello.

Prenons le cas où SpanishSpeaker ne peut pas Dire Bonjour donc, dans ce cas, vous pouvez remplacer la méthode SayHello pour l'espagnol de haut-Parleur et d'élever la bonne exception.

Veuillez noter que nous avons
n'a apporté aucune modification à l'Interface
ISpeaker. Et le code du client et
SpeakerFactory restent également inchangées
inchangé. Et c'est ce que nous faisons par de Programmation-à-Interface.

Et nous avons pu obtenir ce comportement en ajoutant simplement une base de classe abstraite de haut-Parleur et quelques modifications mineures dans la mise en œuvre de l'laissant ainsi le programme d'origine inchangé. C'est une fonction de votre choix de n'importe quelle application et il rend votre application facilement maintenable.

public enum Language
{
English, German, Spanish
}
public class SpeakerFactory
{
public static ISpeaker CreateSpeaker(Language language)
{
switch (language)
{
case Language.English:
return new EnglishSpeaker();
case Language.German:
return new GermanSpeaker();
case Language.Spanish:
return new SpanishSpeaker();
default:
throw new ApplicationException("No speaker can speak such language");
}
}
}
class Program
{
[STAThread]
static void Main()
{
//This is your client code.
ISpeaker speaker = SpeakerFactory.CreateSpeaker(Language.English);
speaker.Speak();
Console.ReadLine();
}
}
public interface ISpeaker
{
void Speak();
}
public abstract class Speaker : ISpeaker
{
#region ISpeaker Members
public abstract void Speak();
public virtual void SayHello()
{
Console.WriteLine("Hello world.");
}
#endregion
}
public class EnglishSpeaker : Speaker
{
public EnglishSpeaker() { }
#region ISpeaker Members
public override void Speak()
{
this.SayHello();
Console.WriteLine("I speak English.");
}
#endregion
}
public class GermanSpeaker : Speaker
{
public GermanSpeaker() { }
#region ISpeaker Members
public override void Speak()
{
Console.WriteLine("I speak German.");
this.SayHello();
}
#endregion
}
public class SpanishSpeaker : Speaker
{
public SpanishSpeaker() { }
#region ISpeaker Members
public override void Speak()
{
Console.WriteLine("I speak Spanish.");
}
public override void SayHello()
{
throw new ApplicationException("I cannot say Hello World.");
}
#endregion
}

Cela signifie que vous devriez essayer d'écrire votre code de sorte qu'il utilise une abstraction (classe abstraite ou une interface) au lieu de la mise en œuvre directement.

Normalement la mise en œuvre est injecté dans votre code par le constructeur ou d'un appel de méthode. Ainsi, votre code sait à propos de l'interface ou une classe abstraite et peut appeler tout ce qui est défini sur le présent contrat. Comme un objet réel (mise en œuvre de l'interface/classe abstraite) est utilisé, les appels sont opérationnels sur l'objet.

C'est un sous-ensemble de la Principe de Substitution de Liskov (LSP), le L de la SOLID principes.

Un exemple dans la .NET serait de code avec IList au lieu de List ou Dictionary, de sorte que vous pouvez utiliser n'importe quelle classe qui implémente IList de façon interchangeable dans votre code:

//myList can be _any_ object that implements IList
public int GetListCount(IList myList)
{
//Do anything that IList supports
return myList.Count();
}

Un autre exemple de la Bibliothèque de classes de Base (BCL) est le ProviderBase classe abstraite - cela offre une certaine infrastructure, et surtout tous les moyens fournisseur implémentations peuvent être utilisés de façon interchangeable si vous code contre elle.

Si vous deviez écrire une Classe de Voiture pendant la Combustion,-ère des Voitures, alors il ya une grande chance, vous pouvez implémenter les oilChange() en tant que partie de cette Classe. Mais, quand les voitures électriques sont introduites, il vous serait en difficulté, comme il n'y a pas d'huile de changement pour ces voitures, et pas de mise en œuvre.

La solution au problème est d'avoir un performMaintenance() de l'Interface dans la classe de Voiture et masquer les détails à l'intérieur de la mise en œuvre appropriée. Chaque type de Voiture donnerait sa propre application pour performMaintenance(). En tant que propriétaire d'une Voiture tout ce que vous avez à traiter est performMaintenance() et ne pas s'inquiéter s'adapter quand il y a un CHANGEMENT.

class MaintenanceSpecialist {
public:
virtual int performMaintenance() = 0;
};
class CombustionEnginedMaintenance : public MaintenanceSpecialist {
int performMaintenance() { 
printf("combustionEnginedMaintenance: We specialize in maintenance of Combustion engines \n");
return 0;
}
};
class ElectricMaintenance : public MaintenanceSpecialist {
int performMaintenance() {
printf("electricMaintenance: We specialize in maintenance of Electric Cars \n");
return 0;
}
};
class Car {
public:
MaintenanceSpecialist *mSpecialist;
virtual int maintenance() {
printf("Just wash the car \n");
return 0;
};
};
class GasolineCar : public Car {
public: 
GasolineCar() {
mSpecialist = new CombustionEnginedMaintenance();
}
int maintenance() {
mSpecialist->performMaintenance();
return 0;
}
};
class ElectricCar : public Car {
public: 
ElectricCar() {
mSpecialist = new ElectricMaintenance();
}
int maintenance(){
mSpecialist->performMaintenance();
return 0;
}
};
int _tmain(int argc, _TCHAR* argv[]) {
Car *myCar; 
myCar = new GasolineCar();
myCar->maintenance(); /* I dont know what is involved in maintenance. But, I do know the maintenance has to be performed */
myCar = new ElectricCar(); 
myCar->maintenance(); 
return 0;
}

Explication complémentaire:
Vous êtes propriétaire d'une voiture qui possède plusieurs voitures. Vous tailler le service que vous souhaitez externaliser. Dans notre cas, nous souhaitons que de sous-traiter les travaux d'entretien de toutes les voitures.

1. Vous identifier le contrat(Interface) qui est valable pour toutes vos voitures et prestataires de service.
2. Les fournisseurs de services en sortir avec un mécanisme pour fournir le service.

3. Vous ne voulez pas à vous soucier de l'associer au type de voiture avec le fournisseur de service. Il suffit juste de préciser lorsque vous voulez planifier l'entretien et à l'appeler. Approprié de l'entreprise de service doit sauter et effectuer les travaux d'entretien.

   Autre approche.

4. Vous d'identifier le travail(peut-être une nouvelle interface Interface) qui est valable pour toutes les voitures.
5. Vous sortir avec un mécanisme pour fournir le service. Fondamentalement, vous allez fournir la mise en oeuvre.

6. Vous appelez le travail et de le faire vous-même. Ici, vous allez faire le travail d'entretien appropriées de travail.

   Qu'est-ce que la baisse de la 2ème approche?
   Vous ne pouvez pas être l'expert à trouver la meilleure façon d'en faire l'entretien. Votre tâche est de conduire la voiture et d'en profiter. De ne pas être dans l'entreprise de son maintien.

   Quel est l'inconvénient de la première approche?
   Il est la surcharge de trouver une entreprise etc. Sauf si vous êtes une société de location de voiture, il peut ne pas être en vaut la peine.

interfaces de décrire les fonctionnalités. lors de l'écriture de code impératif, parlez-en sur les fonctionnalités que vous utilisez, plutôt que de certains types ou classes.