0

I have rows of different types of animals in my Animals table in my database.

I have an IAnimal interface with a Speak method.

I have different animal classes that implement IAnimal interface (Dog, Cat, etc. )

Do you iterate the records check for the type and then instantiate the correct object based on the type and then call their Speak method.

Is that a typical way to use interfaces?

Rod
  • 14,529
  • 31
  • 118
  • 230
  • Sorry I do not understand this. Can you please provide a code or describe what is meant by "interfaces"? :) – Picrofo Software Oct 20 '12 at 20:49
  • 1
    @PicrofoEGY I'm fairly certain the OP means interfaces, as in the language feature that is a part of rather a lot of object oriented and (semi) polymorphic programming languages - such as C#. =) – J. Steen Oct 20 '12 at 20:51
  • In this instance, Animal should be a base object, not an Interface. An Interface implements a "has a" relationship. A base object implements a "is a" relationship. A dog "is a(n)" animal. But a door "has a" doorbell. Use a base class. – scott.korin Oct 20 '12 at 20:52
  • @J.Steen Thanks a lot for providing the information. Have a great day :) – Picrofo Software Oct 20 '12 at 20:54
  • @scott.korin From the way it is *used*, I would have to disagree. Each animal "can" speak. Interfaces tell you what you can do, more or less, yes? =) – J. Steen Oct 20 '12 at 20:56
  • @ J. Steen: I dunno. I am not aware of any animals that doesn't communicate some way or another. Not all animals walk, though. Animal would be a base class, IWalkingAnimal would be an interface. See: http://stackoverflow.com/questions/56867/interface-vs-base-class – scott.korin Oct 20 '12 at 21:06
  • @scott.korin Oh hey. Interesting point, and distinction. However, the method of communication is not the same for every animal - so a shared implementation would be wrong for the .Speak method. – J. Steen Oct 20 '12 at 21:07

4 Answers4

4

You don't need to care about the type of your object, if you know it implements IAnimal.

var animal = (IAnimal)animals[i];
animal.Speak();

Check the reference, which includes samples.

Michal Klouda
  • 14,263
  • 7
  • 53
  • 77
  • Assuming when the object is created to begin with and inserted into the array, it was created as the right object. But then, Animal is really a base class, not an interface. – scott.korin Oct 20 '12 at 20:50
2

No this isn't the typical way, basically you'd have a method that took an instance of the interface, then you could call the Speak method in there. You don't have to care what concrete type the object you passed in is, the beauty of this is you can add many more types in time and not have to change your implementation.

Something like this:

public void Speak(IAnimal animal)
{
    animal.Speak();
}
Mathew Thompson
  • 55,877
  • 15
  • 127
  • 148
1

If you are trying to represent derived types in a relational database, you have the following options:

  1. Each derived type has its own table (e.g. different table for Dog, Cat, etc)
  2. You store all objects in the Animal table and specify the type in a column
  3. You have one Animal table with the common columns between the animals, and separate tables for the specific columns.

It appears that you've selected option 2.

You will typically use the IAnimal interface as a return type of a method or a parameter to another method, rather than instantly calling the speak method right after instantiation.

For example the following code might make sense for interface usage:

public IList<IAnimal> GetAnimals()
{
    var animals = new List<IAnimal>();
    foreach(var animal in db.Animals)
    {
        animals.add( // instantiate new animal here)
    }
    return animals;
}

This would allow a caller to make all the animals speak, regardless of their underlying type. Of course if the interface just has a speak method it probably isn't terribly useful.

Zaid Masud
  • 13,225
  • 9
  • 67
  • 88
1

In this instance, the type of relationship you are talking about is a "is a" relationship. A dog is an animal. "Is a" relationships in object oriented design are implemented using a base class, not an Interface.

So you have a base class of Animal. You then have a class of Dog that inherits from Animal.

When you retrieve your data from your database, you would create each animal as it's type, but add to a List of Animal.

Your calling function can then iterate through the List of Animal objects and call Speak without having to know what each object is.

public void MakeAnimalsSpeak()
{
    // gets your animals from the database
    List<Animal> animals = GetAnimals();

    foreach(Animal animal in animals)
    {
        animal.Speak();
    }
}

private List<Animals> GetAnimals()
{
    List<Animal> animalsToReturn = new List<Animal>();

    // get data from db

    // loop through data

        // switch on "type" field, create correct object.

        // add too List.

    return animalsToReturn;
}
scott.korin
  • 2,537
  • 2
  • 23
  • 36
  • On a theoretical level, you are right. More functionally, it's all about how you describe your context. We could just say that any Animals "has a" way to speak, thus the IAnimal interface. An interface is a Contract binding a class to present a certain behavior. – Yan Brunet Oct 20 '12 at 21:38
  • If I use a switch statement on type and I have a new type down the road I will have to add that case to switch statement and recompile. How would you avoid that? – Rod Oct 20 '12 at 21:46
  • 1
    You could use System.Reflection and Activator. See this : http://msdn.microsoft.com/en-us/library/system.activator.aspx – Yan Brunet Oct 20 '12 at 21:51