What is concrete implementation?

I saw lot of posts in StackOverflow and elsewhere talking about concrete implementati开发者_如何转开发on. While fiddling with WCF i came through the line

Tying your service implementation, or any “service based” class to a concrete implementation is never a good idea.

Can anyone explain what Concrete Implementation is?

It is implementation of something abstract (abstract class, interface). Note that you can instantiate only objects of concrete classes.

Just for example if you have :

abstract class AbstractClass
{
    .......
   // Here you have some abstract methods 
}

class ConcreteClass : AbstractClass
{
.......
}

In case of WCF it wants to say that although it is allowed to mark classes with ServiceContract attribute better to have it on separate Interface and implement that interface in concrete class marked with ServiceBehavior attribute.

Like this :

[ServiceContract(Namespace = "MyNamespaceName")]
interface IMyInterface
{
    [OperationContract]
    int SomeMethod(.....);

   ......    
   ......    
}

[ServiceBehavior(......)]
public class SomethingConcrete : IMyInterface
{
    // implementation of SomeMethod
}

If you have an interface or abstract class, it need to be implemented.

A class that implements such an interface or class is called a concrete implementation (because only such an implemented class can be instantiated).

The principle stated means that you shouldn't code against the concrete implementation directly, as you may want to swap it for another concrete implementation at a later time without changing your code. This means you should use interface and abstract class references instead of concrete implementations.

In the term "concrete implementation", the word "concrete" is redundant. An implementation is always concrete, there is no abstract implementation. So, what's important is just the term "implementation".

What it means in this case is that you should code against an abstraction instead of directly against an implementation, i.e. you define an interface for what the classes has to support, and use the interface instead of the class. That way you can substitute one implementation against another as long as they implement the interface.

I finally understood that from Head First "Design Pattern" Book.

Very Simple explanation.

Imagine there is interface or abstract class called Animal with makeSound() method.

Imagine also there is Dog class with bark() and makeSound() method.

Programming to an implementation(Concrete implementation) Dog class to Animal would be

Dog d = new Dog();
d.bark();

Programming to an interface/supertype Dog class to Animal would be

Animal animal = new Dog();
animal.makeSound();