Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Interface & Class

1>What is the diffrence beteen Interface and Class?
2>How do I identify when to develope and implement custom Interface?

Royald
Thursday, January 27, 2005

You don't write any code in an interface. It serves as a kind of template for a class.

You use it when you have several classes that share method names but not code.

Colm O'Connor
Thursday, January 27, 2005

Where I've used it before:

Two classes that have similar methods (update, insert, delete, etc.) and manage people.

One class - LDAPPerson inserts, updates and deletes on an LDAP server. The other class - SQLPerson inserts, updates and deletes the person on a sql server

I made an interface class interface Person which contains the methods update, insert and delete, but no code.

Colm O'Connor
Thursday, January 27, 2005

I have seen uses of both 'abstract' class and interface interchanged.

The benefit of Interface is that you can use several vs. a class in .NET only has one level of inheritance.

I know this is a java link, but it's worth reading:

http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html

Steve
Thursday, January 27, 2005

The other main difference is that abstract classes can have fields, properties, etc, and non-abstract methods (unless it is pure abstract), so they're not really the same thing.

Nemesis
Thursday, January 27, 2005

You can also put code inside an abstract class, I think. You just can't instantiate it.

Colm O'Connor
Thursday, January 27, 2005

I think these comments are all true but kind of miss the point, which is polymorphism. My favorite explanation of how this all ties together is Bruce Eckel's book Thinking in Java, which is in any case a wonderful book.

NetFreak
Thursday, January 27, 2005

And, for what it's worth, interfaces support properties.

Brad Wilson
Friday, January 28, 2005

Think of an Interface as a "contract".  When a class implements an interface it has to "abide" by the rules of the Interface (ie, implement its methods and data).

Mike McGrath
Friday, January 28, 2005

In C#, interfaces are "sort of" a way to achieve multiple inheritance. (Very sort of)

Imagine having a pocket full of things. Some of the things are coins, some are paper money, some are lint, some are odd bits of string.

Coins and paper money can be "spent" while odd bits of string cannot, other than perhaps in some sort of peculiar barter-based economy.

Consider this simple interface:

interface ISpendable{
  public void Spend();
}

Now, let's say that you have a class like this:

class Money{
public decimal FaceValue;
public string Country;
}

And further:

class DollarBill : ISpendable{

  public void Spend()
  {
  //Implementation of "Spend" goes here.
  }
}

So at this point, you have Money, and a DollarBill, which is ISpendable.

Why not just force all money to implement Spend(), by making it part of the Money class?

Consider this:

class RareCoin : Money{
public decimal CollectibleValue;

  public void SellToCollector()
  {
  //You can't spend it at a store, but you can still sell it.
  }
}

You do not want to spend a rare coin, but it is certainly of the type "money."

If you were looking through your pocket and found a doubloon, it would NOT be spendable, nor would you want to be able to spend it, in any traditional sense.

Imagine now that your pocket is an ArrayList or other collection, filled with various objects. As you iterate the collection, you can inspect each object and make decisions:

foreach(object obj in PocketCollection)
{
  if(obj is ISpendable)
  {
    (obj as ISpendable).Spend();
  }
}

Obviously there is information missing from the Spend() method, but it's just for illustration anyway.

Dave Mays
Saturday, January 29, 2005

And of course, I mis-typed the DollarBill class...

This is what I meant:

class DollarBill : Money, ISpendable
{

}

Dave Mays
Saturday, January 29, 2005

*  Recent Topics

*  Fog Creek Home