locked
Interfaces define Contracts? what does it mean exaclty..? RRS feed

  • Question

  • User1963472758 posted

     have read this line many times " Interface define Contracts" what
    does this mean technically, can please explain me with an example, also
    i want to know whether having interfaces for all your classes is good
    idea?

     Every time i read about interfaces i see how to write an interface, but i know how to write, the question is what are the design situations where i will need an interface

     

    Suppose we take an order system having customers ..orders..products etc, if i have to desing this scenario..wher would interface fits in?

    i know i have asked too many questions ..please respond and any one of experts can come up with an article ..would do great service to beginners like us

     

    Thanks in advance

     

    Sunday, September 3, 2006 6:13 AM

Answers

  • User-389939489 posted
    Hello praveen:

    > have read this line many times " Interface define Contracts"
    > what does this mean technically, can please explain me with an example

    Think of this: you are going to code a class that leverages a support class to do some of the computation. A collegue of yours is to code the support class. Before start coding, you both sit down and define together an interface, so that you can code against the interface, and your collegue can implement it as he likes, and maybe change the implementation in time, provided it also sticks to the interface declaration. As far as the interface remains stable, you both have not to worry about each other's work.

    > i want to know whether having interfaces for all your classes is good idea?

    So, no. Interfaces are good to decouple components and layers. You don't need interfaces everywhere...

    I guess they are called "contracts" because of the impact to people's work, but i'm not English mother-tongue, so please correct this if wrong.

    HTH. -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 8:43 AM
  • User-158764254 posted

    > i want to know whether having interfaces for all your classes is good idea?

    So, no. Interface are good to decouple components and layers. You don't need interfaces everywhere...

    Since decoupling is such a powerful aspect of interfaces lets expand this thought slightly.

    imagine that you have 3 different classes for representing Orders

    • ProductOrder
    • ServiceOrder
    • AfterMarketOrder

    When it comes time to save the order, you have a method:  SaveOrder(order as ??????)

    you need to define but a single type for the order argument in the SaveOrder method.
    if your order classes do not implement an interface, then you might end up with several overloads to your save method:

    • Overloads SaveOrder(order as ProductOrder)
    • Overloads SaveOrder(order as ServiceOrder)
    • Overloads SaveOrder(order as AfterMarketOrder)
    each of these save methods might actually do the exact same thing.
    Now lets add an interface to each order class named: IOrder
    SaveOrder now becomes but a single method:
    • SaveOrder(order as IOrder)
    It can accept instances of any of your order classes that implement the IOrder interface.
    Now your boss asks you to implement a brand new order type:  SuperSpecialGoldCustomerOrderWithExtraDiscounts()
    when you create this new order class, you would also implement the IOrder interface.
    Your existing SaveOrder method will happily accept this new order class and save it since it adhered to the interface.
    SaveOrder() will actually accept any class that implements IOrder.
    SaveOrder() has been decoupled from the exact type of the order class.
    Keep LudovicoVan's point in mind when designing your system: You don't need interfaces everywhere...
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 9:10 AM
  • User-389939489 posted

    mbanavige has complemented it very well.

    About Interface vs Abstract class, you can find articles on the internet: http://www.google.com/search?hl=en&lr=&q=interface+vs+abstract+class&btnG=Search

    In instance look here, and check the "Core VS Peripheral" and "Homogeneity" points into the comparison table: http://www.codeproject.com/csharp/AbstractsVSInterfaces.asp

    Feel free to ask more in case of doubts. 

    HTH = Hope This Helps :)

    -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 9:47 AM
  • User-158764254 posted

    Abstract classes define a more familly like structure where the class that implements it "is a" type of that abstract class, interface don't have anything to do with defining the type of a class ( I thnk :) ).  Someone correct me if I'm wrong.

    Correction:

    Interfaces actually do represent a Type or an "is a".  I would not say that they impose behaviour on a class.

    consider this:

    Public Class Dog 'our abstract/base class
        Implements IAnimal 'an interface
    End Class

    Public Class Poodle
        Inherits Dog 'base class
    End Class

    Dog "Is a" IAnimal
    Poodle "Is a" Dog
    Poodle "Is a" IAnimal

    Now let consider the notion of behaviour.
    IAnimal defines that a method will exist: Speak

    The Speak() method has no bahaviour defined by the interface as the implementation (the bahaviour) is left to the implementing class.
    The interface simply requires that "Speak" exist - this is the contract.

    The Dog base class implements Speak (as it is required to do by the IAnimal interface) 

    Public Overridable Sub Speak Implements IAnimal.Speak
        "Woof" 'now we have a basic behaviour inherited from our base class
    End Sub

    Poodle overrides the base class and changes the behaviour
    Public Overrides Sub Speak
        "Woof Woof Woof"
    End Sub

    If a Cat class had implemented IAnimal - it would "meow" when you called its Speak() method.

    One significant difference between the interface and the abstract/base class is that the interface does not and cannot contain an implementation. i.e. no code
    The abstract/base class on the other hand can contain an implementation (code) - but doesnt have to.

    Another significant point is that a class may inherit only one base class as multiple inheritance (implementation inheritance) is not supported in .NET
    on the other hand, a class my implement as many interfaces as it needs to.

     Now lets consider several class that all implement IAnimal (either directly or through inheritance)

    Dim snake as new Snake
    Dim dog as new Dog
    Dim cat as new Cat

    Aslo lets add a method:

    Public Sub StepOnTail(animal as IAnimal)
        animal.Speak()
    End Sub

    Given that IAnimal represents an "Is a" or a type, we can pass all of our animal classes to this single method

    StepOnTail(snake) 'results in a hiss
    StepOnTail(dog) 'results in a woof
    StepOnTail(cat) 'results in a meow

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 5, 2006 8:05 PM

All replies

  • User-389939489 posted
    Hello praveen:

    > have read this line many times " Interface define Contracts"
    > what does this mean technically, can please explain me with an example

    Think of this: you are going to code a class that leverages a support class to do some of the computation. A collegue of yours is to code the support class. Before start coding, you both sit down and define together an interface, so that you can code against the interface, and your collegue can implement it as he likes, and maybe change the implementation in time, provided it also sticks to the interface declaration. As far as the interface remains stable, you both have not to worry about each other's work.

    > i want to know whether having interfaces for all your classes is good idea?

    So, no. Interfaces are good to decouple components and layers. You don't need interfaces everywhere...

    I guess they are called "contracts" because of the impact to people's work, but i'm not English mother-tongue, so please correct this if wrong.

    HTH. -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 8:43 AM
  • User1963472758 posted

    Thanks HTH-LV  ( nice name ) , for early reply,  so it is more a framework issue?  can say just have interfaces before you start your project coding so maintain a standard and naming conventions? and allow multiple people to work on a given interface so that a part of interface can be implemented by people in thier own way?

     so dont i choose Abstract class in such case?

    thanks still i need to understand,

    Sunday, September 3, 2006 9:05 AM
  • User-158764254 posted

    > i want to know whether having interfaces for all your classes is good idea?

    So, no. Interface are good to decouple components and layers. You don't need interfaces everywhere...

    Since decoupling is such a powerful aspect of interfaces lets expand this thought slightly.

    imagine that you have 3 different classes for representing Orders

    • ProductOrder
    • ServiceOrder
    • AfterMarketOrder

    When it comes time to save the order, you have a method:  SaveOrder(order as ??????)

    you need to define but a single type for the order argument in the SaveOrder method.
    if your order classes do not implement an interface, then you might end up with several overloads to your save method:

    • Overloads SaveOrder(order as ProductOrder)
    • Overloads SaveOrder(order as ServiceOrder)
    • Overloads SaveOrder(order as AfterMarketOrder)
    each of these save methods might actually do the exact same thing.
    Now lets add an interface to each order class named: IOrder
    SaveOrder now becomes but a single method:
    • SaveOrder(order as IOrder)
    It can accept instances of any of your order classes that implement the IOrder interface.
    Now your boss asks you to implement a brand new order type:  SuperSpecialGoldCustomerOrderWithExtraDiscounts()
    when you create this new order class, you would also implement the IOrder interface.
    Your existing SaveOrder method will happily accept this new order class and save it since it adhered to the interface.
    SaveOrder() will actually accept any class that implements IOrder.
    SaveOrder() has been decoupled from the exact type of the order class.
    Keep LudovicoVan's point in mind when designing your system: You don't need interfaces everywhere...
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 9:10 AM
  • User-389939489 posted

    mbanavige has complemented it very well.

    About Interface vs Abstract class, you can find articles on the internet: http://www.google.com/search?hl=en&lr=&q=interface+vs+abstract+class&btnG=Search

    In instance look here, and check the "Core VS Peripheral" and "Homogeneity" points into the comparison table: http://www.codeproject.com/csharp/AbstractsVSInterfaces.asp

    Feel free to ask more in case of doubts. 

    HTH = Hope This Helps :)

    -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, September 3, 2006 9:47 AM
  • User1290287685 posted

    as far as I understand it, a big difference between interfaces and abstract classes is that a class can use many interfaces, while it can only implement one abstract class.  So interfaces can provide for some sort of multi behaviour definition of classes, but not multi-inheritance.

    I think interfaces are sometimes referred to as contracts because they are more for imposing rules and behaviour on classes.  Abstract classes define a more familly like structure where the class that implements it "is a" type of that abstract class, interface don't have anything to do with defining the type of a class ( I thnk :) ).  Someone correct me if I'm wrong.

     

    Tuesday, September 5, 2006 3:21 PM
  • User-158764254 posted

    Abstract classes define a more familly like structure where the class that implements it "is a" type of that abstract class, interface don't have anything to do with defining the type of a class ( I thnk :) ).  Someone correct me if I'm wrong.

    Correction:

    Interfaces actually do represent a Type or an "is a".  I would not say that they impose behaviour on a class.

    consider this:

    Public Class Dog 'our abstract/base class
        Implements IAnimal 'an interface
    End Class

    Public Class Poodle
        Inherits Dog 'base class
    End Class

    Dog "Is a" IAnimal
    Poodle "Is a" Dog
    Poodle "Is a" IAnimal

    Now let consider the notion of behaviour.
    IAnimal defines that a method will exist: Speak

    The Speak() method has no bahaviour defined by the interface as the implementation (the bahaviour) is left to the implementing class.
    The interface simply requires that "Speak" exist - this is the contract.

    The Dog base class implements Speak (as it is required to do by the IAnimal interface) 

    Public Overridable Sub Speak Implements IAnimal.Speak
        "Woof" 'now we have a basic behaviour inherited from our base class
    End Sub

    Poodle overrides the base class and changes the behaviour
    Public Overrides Sub Speak
        "Woof Woof Woof"
    End Sub

    If a Cat class had implemented IAnimal - it would "meow" when you called its Speak() method.

    One significant difference between the interface and the abstract/base class is that the interface does not and cannot contain an implementation. i.e. no code
    The abstract/base class on the other hand can contain an implementation (code) - but doesnt have to.

    Another significant point is that a class may inherit only one base class as multiple inheritance (implementation inheritance) is not supported in .NET
    on the other hand, a class my implement as many interfaces as it needs to.

     Now lets consider several class that all implement IAnimal (either directly or through inheritance)

    Dim snake as new Snake
    Dim dog as new Dog
    Dim cat as new Cat

    Aslo lets add a method:

    Public Sub StepOnTail(animal as IAnimal)
        animal.Speak()
    End Sub

    Given that IAnimal represents an "Is a" or a type, we can pass all of our animal classes to this single method

    StepOnTail(snake) 'results in a hiss
    StepOnTail(dog) 'results in a woof
    StepOnTail(cat) 'results in a meow

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 5, 2006 8:05 PM
  • User1290287685 posted
    thanks for the correction... that makes sense.
    Tuesday, September 5, 2006 10:39 PM
  • User1963472758 posted
    Thanks very much, and i promise i have read so much of it and your example ..just clears everything ...   a *****  rating
    Wednesday, September 6, 2006 2:44 PM
  • User1963472758 posted
    Thanks very much, and i promise i have read so much of it and your example ..just clears everything ...   a *****  ratingg
    Wednesday, September 6, 2006 2:45 PM
  • User-727537350 posted

    Thats an amazing example Mike. Makes it completely clear.

     

    Thanks,

    Chandra. 

    Tuesday, April 20, 2010 10:08 AM