OO and U

[cheung31]

Photon's recent example is polymorphism in action.

That animal interface, like Photon mentioned, is contractual. So an implementation of Animal interface, say, Cat should expect to have an Eat method implemented. Same with Crocodile or Dog. However, Eat may have slightly different behaviors between each animal type, Cat/Crocodile/Dog. (Type-specific behavior)

As a fellow programmer who wanted to use your Animal interface, I know that any subclass implementation (any animal I choose to create in the future) will have a Eat method that I can call because I had to implement it (contractual interface). Now imagine my client code is a representation of my farm. I will represent all the animals of my farm with some collection, say, an array/list composed of Animal instances. I can iterate over each element of this array/list, and call Eat() on the Animal instance. Each Animal instance will make the correct method call of its respective Animal type.

Polymorphism is possible due to late binding, where at runtime, the correct method is invoked based on the type of a particular object.

[BlackEleven]

^ Personally, if I had an Animal class and bunch of different types of animals, I'd prefer to use inhertiance over interfaces.

As for a real world example of interfaces consider SDKs. Say you had an SDK that allowed you to create a type of server. All clients of this type of server have certain calls that they can make, so this server must be able to respond to all of them otherwise you're going to get a bunch of errors. One way to force you to implement all these calls is to provide you with an interface. Like has been said, its a contract, so the person that provides you with the SDK can be certain you will implement all the methods required by the clients.

[kermitology]

Interfaces also allow you to do multiple inheritance don't they? At least in Java and Objective C you can only have one super class, but you can implement functionality of other classes as interfaces.

[photon]

Boo multiple inheritance!

*hugs Java*

[FanIn80]

Wow, there's a lot of stuff here to digest... We're getting into inheritance next week, so some of this should make more sense then.

I'm getting the hang of this interface stuff now, though. I thought he was saying that it was meant for writing a method once and then sharing it amongst different classes, but now I see what it is. It makes a lot more sense now. It's just a way of tying a bunch of classes together and making sure they all use the same methods... well, in addition to their own methods.

Also, he had mentioned that it can be used as a way to divide work amongst different teams. I kind of get that part already. Team collaboration was one of the first things I thought of when I saw him setting up the lab. Then I got all messed up with the way he was explaining the "sharing classes" aspect of it.

[MickMcGeough]

Originally Posted by kermitology

Interfaces also allow you to do multiple inheritance don't they? At least in Java and Objective C you can only have one super class, but you can implement functionality of other classes as interfaces.

Hardly. I love me some java but implementing from multiple interfaces is not multiple inheritance.

[BlackEleven]

Originally Posted by FanIn80

I thought he was saying that it was meant for writing a method once and then sharing it amongst different classes, but now I see what it is.wn

That's what inheritance is for, with the notable exception of virtual functions. I'm a C++ guy, so I'm not sure if the concept of a virtual function exists in C# or Java.

[photon]

Yes virtual functions are pretty key to OO so they are there. In Java all methods are virtual functions unless you mark them as final or they are private, in C# I think it's the opposite where you have to explicitly mark a method as virtual and explicitly mark the overriding method too.

[Shazam]

C# lets you hide methods even if they're not marked virtual. It's a bit screwy, actually.

[FanIn80]

Just a quick /bump to thank you guys again for your posts in this thread. I just finished the class with my final yesterday (hasn't been graded yet), and I'm feeling pretty good about things.

We covered instantiation, classes, interfaces, inheritance, polymorphism, file IO (not really an OO thing)... it was a pretty awesome course. I think it was my favourite one so far. Now I'm just sitting here trying to think of some kind of project I can do for practice...

Edit: Whoops. Forgot to mention UML diagrams, IPO charts, skeleton code, flow charts, etc etc. Error handling (try, catch, finally)...

Anyway, I would have had a much harder time figuring it all out without this thread, so thanks again!

[FanIn80]

Soooo… Polymorphism.

I get that it's about super and sub classes, and that you make an Animal super class followed by a sub class for Tiger or Elephant, etc. I also get that you'd implement an Eat or Run method in each…

My question is with making the super class abstract. I understand wanting to bullet-proof your app by blocking other developers from instantiating the super class… but how is an abstract super class different from an interface? Isn't it just a fancy way of making another contract, since all sub classes have to inherit the methods from the super class? I know you can have both abstract and concrete methods inside an abstract super class (you have to override the abstract ones before you can inherit them), but…

Anyway. This stuff is awesome, but I'm still getting my head around some of it.

[BlackEleven]

An abstract base class and an interface are similar but not exactly the same. You partially answered your own question, but another difference is that interfaces don't have the concept of private/protected functions.

In my professional experience, interfaces are used far less than polymorphism because you're allowed more flexibility when working with inheritance.

[yads]

BlackEleven, seriously, you've seen interfaces used far less than abstract classes? What is your experience exactly?

FanIn80, think of an Interface as a contract. It defines how to interact with it, but not how that interaction is implemented. A class that implements an interface will then define an implementation of those interactions. Take an interface for a datastore. It might define some methods like Save, Load, and Delete.

It might looks like this:
public inteface IDataStore
{
void Save(object obj);
void Delete(object obj);
object Load(int key);
}

Now that interface can be used in your application to maintain persistent data. You can then have multiple implementations for it. For example.

public class FlatFileDataStore : IDataStore
{
public void Save(object obj) { /* write to file */ }
public void Delete(object obj) { /* delete from file */ }
public object Load(int key) { /* load from file */ }
}

public class DatabaseDataStore : IDataStore
{
public void Save(object obj) { /* write to db */ }
public void Delete(object obj) { /* delete from db */ }
public object Load(int key) { /* load from db */ }
}

As for abstract classes, they are classes that cannot be instantiated. It may also have abstract methods and properties that will then be defined by sub classes. An example might be a controller class.

public abstract BaseController
{
public void Init()
{
//do some common stuff here
OnInit();
}
protected abstract void OnInit();
}

Let me know if you have more questions.

[yads]

Oh and this, (just replace C++ with C# and it's the same thing).

[BlackEleven]

Originally Posted by yads

BlackEleven, seriously, you've seen interfaces used far less than abstract classes? What is your experience exactly?

C++.

And I didn't say abstract base classes, I said polymorphism. In C++ an interface is basically just an abstract base class where all the functions are public and pure virtual (except the destructor, because ploymorphic destruction is generally evil). What I meant is that I rarely see a class where every function is pure virtual.

[yads]

Ah, fair enough. I find a lot of poorly written application make sparse use of interfaces if at all. Hence my comment.

[MickMcGeough]

Originally Posted by BlackEleven

In my professional experience, interfaces are used far less than polymorphism because you're allowed more flexibility when working with inheritance.

Uh, what?

How can interfaces & polymorphism be mutually exclusive? Don't confuse the student here!

[FanIn80]

So what would be a situation where...

public interface IAnimal {
    void Eat();
    void Run();
}

public class Dog implements IAnimal {
	public void Eat() {
		System.out.println("I am a dog, eating a cat.");
	}
	public void Run() {
		System.out.println("I am running from a tiger.");
	}
}

public class Cat implements IAnimal {
	public void Eat() {
		System.out.println("I am a cat, eating a mouse.");
	}
	public void Run() {
		System.out.println("I am running from a dog.");
	}
}

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog();
        Cat c = new Cat();
        
        c.Eat();
        c.Run();
        d.Eat();
        d.Run();
    }
}

...would be used instead of...

abstract public class Animal {
    abstract void Eat();
    abstract void Run();
}

public class Dog extends Animal {
    public void Eat() {
        System.out.println("I am a dog, eating a cat.");
    }
    public void Run() {
        System.out.println("I am running from a tiger.");
    }
}

public class Cat extends Animal {
    public void Eat() {
        System.out.println("I am a cat, eating a mouse.");
    }
    public void Run() {
        System.out.println("I am running from a dog.");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog d = new Dog();
        Cat c = new Cat();
        
        c.Eat();
        c.Run();
        d.Eat();
        d.Run();
    }
}

...this (or vice versa)?

[BlackEleven]

There is no difference there. Those two things are functionally equivalent.

But to the second example I could add something like

protected String food;

Because my variable is protected I can control access to it. For example, I could make sure that the Eat method is the only way the dog's food can be consumed. I don't have to worry about some idiot using my class using dog.food to screw things up for me.

I don't have anyway of doing this with an interface where everything is public.

[yads]

The first would be used if it logically made sense. Now the examples you gave are contrived examples and don't really help to understand when you would use one over another. Part of the problem of using abstract concepts like Animal. Think of this situation:

You have a Car. A car uses the following components: Engine and Brakes. A Car might have the following methods: Accelerate and SlowDown. An engine might have methods like Engage and Disengage. Brakes might have a method like Apply.

In this situation one might think that a Car could be an abstract class and Engine and Brake could be interfaces. So let's see what our abstract car might look like

public abstract class Car
{
     private IEngine engine;
     private IBrakes brakes;

     protected Car(IEngine engine, IBrakes brakes)
     {
          this.engine = engine;
          this.brakes = brakes;
     }

     public void Accelerate()
     {
           engine.Engage();
     }

     public void SlowDown()
     {
          engine.Disengage();
          brakes.Apply();
     }

     public asbtract int NumberOfDoors { get; }
}

now classes that inherit Car must define NumberOfDoors and also might have other components. For example a ModernCar class might have a computer, but all Cars accelerate and decelerate the same way.

Now the reason that engine and brakes might be interfaces is because the car doesn't really care about the object implementing it and only cares about the facade that interfaces expose. So you could have implementors like FourCylinderEngine and V8Engine, but all the consumers of these engines care about are the Engage and Disengage facade.

The other more technical reason you would use interfaces over classes is due to the single inheritance limitation that is present in most modern languages. This limitation means that a class can only inherit from at most one other class. However, it can implement many interfaces. So our FourCylinderEngine class might not only implement the IEngine interface, it might implement an IPowerSource interface that might define different methods/properties like TotalPowerOutput, things like that.