Meaning of Types, Class, Interface?

Question

Find many authors interchangably use the term Type and Class. Certain textbooks covering object based model covers the term Interface also.

Could someone please explain these in simple terms based on Object Oriented Programming in general and C++/Java/object-oriented-database in particular.

Answer 1

A type is a classification of a piece of data telling you what its permissible values and permissible operations are. (Almost?) all programming languages have types, although the typing discipline varies considerably from one language to another.

A class is a particular kind of type in OOP languages which is defined with a specific syntax in the language itself (as opposed to, say, so-called "native types" like Java's int or float or the like which are defined by the language proper). A class is typically defined in terms of a memory layout and encoding of data (so-called member variables) and the functions that work on them (so-called member functions or methods).

An interface* is a specification of what operations a type must implement to be considered part of a given set of similar types but which does not specify permissible values, memory layouts, etc.

This is a very, very, very brief overview that is kind of the simplified "average form" of several languages' approach to these. It ignores a few edge cases and things like C++'s ability to make things that are part-way between an interface and a class. It also ignores what classes are in functional languages like Haskell because damaging your brain farther is not the goal here. ;)

---

edited to add some examples

Here are some Java-like declarations to help cement the concepts.

int myVariable1;

This variable—myVariable1—is a native (or primitive) type consisting of a 32-bit signed integer value encoded in 2s-complement notation. It has a known range (of approximately -2 billion to +2 billion) and a known set of operations (multiplication, addition, division, modulus, subtraction, various conversions, etc.) available to it.

class MyClass
{
  int myMemberVariable;
  int myOtherMemberVariable;
  int myMethod(int p) { myMemberVariable += p; myOtherMemberVariable = p; }
}
MyClass myVariable2 = new MyClass();

Here myVariable2 is a type defined by the class MyClass. MyClass defines the memory layout (which in this case consists of two 32-bit signed integers in 2s-complement notation) as well as the single operation myMethod() which adds its argument to myMemberVariable and sets myOtherMemberVariable to that argument.

interface MyInterface
{
  int myInterfaceMethod(int p, int q);
}

Here MyInterface only declares a set of operations (consisting in this case of the single function myInterfaceMethod()) without any member variables and without any implementation. It only tells you that any class that implements this interface is guaranteed to have a method with that specific signature of name + return value + arguments. To use it you have to make a class that implements the interface.

class MyOtherClass implements MyInterface
{
  int myMember1;
  int myMember2;
  int myMember3;
  int myInterfaceMethod(int p, int q) { myMember1 = p; myMember2 = q; myMember3 = p - q; }
  int myNonInterfaceMethod() { return myMember1; }
}
MyOtherClass myVariable3 = new MyOtherClass();

Now myVariable3 is defined as a type with a memory layout consisting of three signed 32-bit integers and two operations. One of those operations is one it must implement because of the whole implements MyInterface portion. This way anything that's expecting the (abstract) MyInterface type can use the (concrete) MyOtherClass type since the operation is guaranteed to be there. The other method—myNonInterfaceMethod()—does not come from MyInterface so something that is expecting only a MyInterface can't use it because it can't know it exists.

---

further edited to add some real-world stuff by request

If you've ever used an integer value, a floating point value, a string or anything like this in a program you've used types. Types are arguably the stuff of computing and everything we do is manipulation of values of given types. I'll focus, therefore, on the OOP-specific notions of classes and interfaces.

Any time you have data and operations on that data you have the potential for a class. Take, for example, a bank account. A bank account will have, among other things, an account number, a current balance, a transaction limit, etc. A class representing this (badly and shown only to explain concepts) might look like this:

class BankAccount
{
  String accountNumber;
  float balance;  /* DO NOT USE FLOATING POINT IN REAL FINANCIAL CODE! */
  int transaction_limit;
  float transaction(float change) {
    balance += change > transaction_limit ? transaction_limit : change;
    return balance;
  }
}

Now you can make a variable of this type and know that it will carry around an account number (which is itself a String type), a balance (which is itself a float type -- but DON'T USE FLOATING POINT IN REAL WORLD FINANCIAL CODE!) and a transaction limit (which is itself an int type). You also know you can perform a transaction (creatively called transaction) which will check the change against the transaction limit and modify the balance. (A real class for this would contain lots more and would contain a lot of obfuscatory protection stuff that I've removed for pedagogical purposes.)

Now let's say you're in a more sophisticated financial environment in which there are several kinds of transactions, not just bank accounts. Let's say further you've got some code that will process transactions that doesn't care what the specifics of the underlying types are. An offline batch processor of transactions, say, that covers bank accounts, accounts receivables accounts, etc. Rather than making it know about every kind of transaction in the book, we can do this instead:

interface Transactable
{
  float transaction(float change);
}

class BankAccount implements Transactable
{
  /* interior is identical */
}

class ReceivablesAccount implements Transactable
{
  float balance;
  float transaction(float change) { balance += change; }
}

Now anything that knows about Transactable types can use both your BankAccount's instances as well as your ReceivablesAccount's instances. They don't have to know that bank accounts have transaction limits while receivables accounts don't. They don't have to know anything about the internal representation of the data. They don't have to know the special cases of anything. They just have to know about one function by name (transaction()) and that's it. (If you want more concrete real-world usage of this, look at how the collection classes, not to mention the "for in" loop, use the Iterable interface in Java.)

Answer 2

In O.O.P parlance is very common to use the Terms Type and Class interchangeably, especially when talking about some languages like java and/or C++.

Generally speaking, when you define a Class you're actually defining a Type template, from which objects of the Type you're defining will be created, and/or instantiated.

The concept of interface is a little bit more complicated, when you define an interface you're basically specifying a particular way to deal with any Type of object that does use of it. That is, your object must come from a class that implements that interface. An interface is a way of enhancing your Class/Type by specifying additional behavior not contained in the original Class/Type specification.

For many practical purposes you can treat an Object thorough it's interface as if it were of the interface type, that's probably why the term interface is used interchangeably with the term type.

See the theory behind Abstract Data Types for further insight.

Answer 3

Personally, I think it's easier to understand if you describe it in concrete terms. For example, let's say we want to build a program to track inventory of things in a kitchen.

Most languages only know about very simple, primitive "Types" of things like integers, characters, and bytes. We could totally use these primitive Types to describe the types of things in a kitchen. For example, you could construct an array of an array of characters where each index in the array represents an attribute of something. Like, maybe, index 0 represents the "type" of thing you're trying to describe. But, of course, this technique would get very complicated very quickly.

So, using Object Oriented techniques, we can easily define new Types by combining primitive Types. The way that you do that is by creating a Class definition. Think of a Class as a blueprint for a new Type.

In the kitchen example, we have the concept of "Food" Type, "Appliance" Type, and "Furniture" Type. In order to use these new types in the program, we'd need to create a class definition for each of these:

public class Food {...}
public class Appliance {...}
public class Furniture {...}

An Interface describes how we can interact with something. For example, we want to create an inventory of things in our kitchen. We will want to be able to "Add" to our inventory, "Remove" things from our inventory, and maybe "Iterate" over our inventory. The actions "Add", "Remove" and "Iterate" apply to pretty much any list of anything (not just our inventory). Java provides an interface named "List" for this purpose. By creating an inventory object with the very popular and common List "Interface", we get all the actions for free and other programmers can look at our program and know exactly how to interact with the "Inventory" object:

...
java.util.List inventory = new ArrayList(); 
...
//later in our program, we can interact with inventory
//  with any of methods on the list interface (because ArrayList "implements" List)
inventory.add(new Furniture("chair"));
inventory.add(new Appliance("refrigerator"));
inventory.add(new Food("ice cream"));
...

So, in the example above, inventory is variable that contains an instance of type ArrayList. Since the ArrayList Class definition implements the "List" interface, all instances of Type ArrayList must obey the contract defined in the the "List" interface. In other words, we could have just as easily created inventory as a LinkedList (instead of an ArrayList) like this:

java.util.List inventory = new LinkedList();

Remember to think of an interface as a contract that exposes a specific set of actions to be preformed. Because LinkedList and ArrayList both implement the "List" interface, they are both contractually obligated to implement all the methods in the "List" interface.

The great thing about this is that any code that is interested in using our "inventory" variable doesn't give a crap about how the "add", or "remove", or "iterator" actions are implemented. All they care is that the variable "inventory" obeys the "List" interface.

In other words, LinkedList implements the "add" method slightly different than ArrayList. But that doesn't matter to any code that wants to use our "inventory" variable.

If some math whiz comes up with a revolutionary way to store lists. Maybe they figure out how to store lists on the moon rather than inside computer memory and that turns out to be 10x faster than ArrayList. Then all we'd need to do is this:

java.util.List inventory = new CrazyMoonList();

All the other code that uses inventory can stay exactly the same because CrazyMoonList is guaranteed to provide "add", "remove", etc.

Hope this helps clarify the concepts!

Answer 4

A class is a template for an object, a user-defined datatype that contains variables, properties, and methods.

//defines a simple class describing all types of fruit
public class Fruit {
    //insert fields here...

    Fruit(){//constructor method
        //insert constructor code here... 
    }

    //insert class methods here.... 
}

When we instantiate this class to be an object, we need to let the compiler know what type of object it is going to be. In this case our object is going to be of type Fruit.

//The initialisation might look something like this. 
Fruit myFruit = new Fruit(); 

The previous line of code tells the compiler to construct a new object of type Fruit.

So in simple terms "class" defines an objects characteristics (its data), where as "type" is refers to what type of object we are looking at when it has been instantiated, whether it be a Fruit, Car, or Desk!

This concept can be expanded upon by reading further into the topics of Inheritance and Polymorphism.

I hope this is of help.