Interface en tant que service dans la programmation basée sur l'interface: Comment implémenter une classe de fournisseur de services contre son client en utilisant l'interface

Question

Tout d'abord, j'espère pouvoir choisir un bon titre pour ma question.

selon le chapitre 7 du livre « The Essential C# » qui tente de décrire l'interface Concept une prise murale est une interface et tous appareils (clients) qui veulent recevoir doit d'alimentation mettre en œuvre cette interface.Ok Ce me fait poser quelques questions simples.

1-Dans notre domaine, il est une entité appelée socket qui est le fournisseur de puissance et autrement dit est Le fournisseur de services, quelle est la relation entre ce fournisseur de service et le service (Interface), et comment nous devons mettre en œuvre la classe Socket.? Quelqu'un peut-il donner un exemple de la mise en œuvre de classe Socket ou donner quelques conseils ou un échantillon de code source? Merci à tous.

2-Si nous regardons Interface comme contrat ou spécification Nous constatons que Parfois, il doit tenir compte de certaines valeurs constantes dans notre contact (ou spécifications) et d'autres ne devraient pas changer et modifier ces éléments et devrait suivre eux exactement comme. The PinsDistance et The PinsLength Dans notre domaine, Mais nous savons que ce n'est pas possible en C# à utiliser Constante dans une interface (en Java Son possible) Comment vous gérez Ce problème.

Un exemple de mise en œuvre de ce numéro est fourni ici.

interface I2PinsWallPlug 
{ 
    void Plug(); 
    void Unplug(); 

    //***** Its Not Allowed To Use Const In an Interface In C# ***** 
     //const int Pinsdistance = 1; 
     //const int PinsLength=5; 
    //***** Its Not Allowed To Use Const In an Interface In C# ***** 
} 

// A sample appliance is As a Client And Must Implemnt The Interface To Recieve Power 
class MyAppliance : I2PinsWallPlug 
{ 
    public void Plug() 
    { 
     //... 
    } 

    public void Unplug() 
    { 
     //... 
    } 


} 

//The Socket Class is Our Service Provider In Here and 
//I dont know My implementation Is Right Or Not ????????????? 
class Socket 
{ 
    public Socket(I2PinsWallPlug twoPinsWallPlug) 
    { 
    } 
} 

Answer 1

client obtient non seulement l'interface du service, mais des entités aussi bien. Il y a des cas où vos paramètres in/out sont des types .NET de base, mais la plupart des autres cas, ce sont des types complexes et doivent être fournis au client.

Si vous n'avez pas une telle entité, vous pouvez peut-être créer une classe de constantes et la fournir aux clients - et c'est ce que j'ai fait il y a quelques jours.

---

Exemple d'une classe pour les constantes

public static class SystemConstants 
{ 

    public static readonly string Foo= "BAR"; 
    public static readonly int[] ValidTypeIdsForBaaz = new int[]{290,291}; 

} 

---

MISE À JOUR - Question 1

dépend de ce que nous entendons par service. Le service est généralement logique et parfois physique. Un service logique vit dans la même limite de processus alors qu'il est extrait par ses clients et qu'un service physique se trouve dans un autre processus sur la même machine ou sur une autre machine qu'un service Web, WCF ou ...

Sans en savoir plus sur votre modèle de domaine - ce que ce service fait réellement - il n'est pas possible de trouver des abstractions. Fournissez quelques informations sur le Socket et nous devrions être en mesure d'aider avec des abstractions.

Answer 2

comment sur l'utilisation d'une classe de base abstraite plutôt que d'une interface

public abstract class I2PinsWallPlug 
{ 
    protected const int Pinsdistance = 1; 
    protected const int PinsLength = 5; 

    public abstract void Plug(); 
    public abstract void Unplug(); 
} 

public class MyAppliance : I2PinsWallPlug 
{ 
    public override void Plug() 
    { 

    } 

    public override void Unplug() 
    { 

    } 
} 

Answer 3

La notion d'interface en C# est plus proche de ce qu'elle devrait être, les interfaces de cause ont rien à voir avec les mises en œuvre et ne doivent pas contenir données ou impl.

"héritage n'est pas sous-typage

Peut-être la confusion la plus commune autour des langages orientés objet est la différence entre le sous-typage et l'héritage La distinction plus simple entre les sous-typage et l'héritage est la suivante:. Le sous-typage est une relation sur les interfaces , l'héritage est une relation sur les implémentations "

Ref: Software Engineering - Cambridge University Press - Concepts en langages de programmation