Interface As Service In Interface Based Programming :How To Implement A Service Provider Class Against Its Client Using Interface

First Of all ,I Hope To choose a good Title For my Question.

according to The chapter 7 Of "The Essential C#" book That Tries to Describe The Interface Concept a wall plug Is an Interface and all of appliances (Clients) that want to recieve AC power must implement this interface.Ok This makes me to ask some simple questions.

1-In our Domain there is an entity called Socket that is the Power Supplier and in other words is The Service Provider,what is the relation between this Service provider and The Service(Interface),and how we must implement The Socket Class.?Could anyone Give a sample Implementation of Socket Class Or Give Some Advices Or Sample Source Code ?Thank u all.

2-If we look at Interface as Contract Or Specification We Find that Sometimes it needs to consider some Constant values in our contact (or specification) and others should not Change and Modify these items and should Follow them exactly .such as The PinsDistance and The PinsLength In our Domain, But we know its not possible in C# to Use Constant in an interface (in Java Its possible) How You handle This i开发者_JS百科ssue.

A Sample implementationn Of This Issue are provided here.

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)
    { 
    }
}

---

how about using an abstract base class rather than an 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()
    {

    }
}

---

The notion of interface in C# is closer to what it should be, cause interfaces have nothing to do with implementations and shouldn't contain any data or impl.

"Inheritance Is Not Subtyping

Perhaps the most common confusion surrounding object-oriented languages is the difference between subtyping and inheritance. The simplest distinction between subtyping and inheritance is this: Subtyping is a relation on interfaces, inheritance is a relation on implementations"

Ref: Software Engineering - Cambridge University Press - Concepts in Programming Languages

---

Client not only gets the interface of the service but entities as well. There are cases where your in/out parameters are purely basic .NET types but most other cases, these are complex types and need to be provided to the client.

If you do not have such entity, you may perhaps create a constants class and provide it to clients - and that is what I have done just a few days ago.

---

Example of a class for constants

public static class SystemConstants
{

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

}

---

UPDATE - Question 1

Depends what we mean by service. Service are usually logical and sometimes physical as well. A logical service lives in the same process boundary while abstracted by its clients and a physical service sits in a another process on the same machine or another machine as a web service, WCF service or ...

Without knowing more about your domain model - what this service actually does - it is not possible to come up with abstractions. Provide some info on the Socket and we should be able to help with abstractions.