[PHP-DEV] MI/Aggregation/Interfaces: simple examples

Tue, 09 Apr 2002 15:53:19 -0700

Hello,
 
for those that are trying to follow the discussion but are not sure of what is what, here are some simple examples that I hope will help you.
 
Inheritance: LivingRoom and Bathroom inherit the attributes and functionalities of a Room. This relationship is called a "is-a" relationship. Room is a base class that represents a physical entity, so they can be extended and instanciated. Conceptual entities like "Engine" are abstract classes that can be extended and not instanciated.
 
Objects must be defined for extension or reuse:
 
For extension:
 
class DisneyCharacter {
   public void create() {
    ...
   }
}
 
class MickeyMouse extends DisneyCharacter {
   public void create() {
      super.create();
   }
}
 
and for reuse:
 
class DisneyCharacter {
   public final void getName {
      return name;
   }
}
 
class MyDisneyCharacter {
    public void getName() { // ILLEGAL
}
 
Interfaces: From Arnold&Gosling 'Java programming language'

The idea of an interface is fundamental part of object-oriented approach. The idea is quite simple an interface defines a contract. It is actually a promise to provide well defined features or functionality. The interface, however, does not say anything about implementation. In Java interface consists of method declarations and, can also contain constant declarations. Suppose that we have several kinds of data sources, several databases, and we want to create a visual browser that will allow us to look at different tables in a database. Say that we have a few Relational databases, and a few proprietary formatted file based databases. In order for us to be able to create single browser for all of them, we must establish some kind of common database interface that all of the database objects should follow. Here is a very simple one: 

public interface IDatabase {
	public String getName();
	public Iterator getTables();
	public Iterator getTableNames();
	public ITable getTable( String table );
}

Now given this interface, we may do the following: 

public class RelationalDatabase implements IDatabase


public class FileDatabase implements IDatabase

We are not concern here with details of these implementation. Implementor will have to adapt to the IDatabase interface. The gain is this: 

public class DatabaseBrowser {
	 public setDatabase( IDatabase db );
}

We can pass either RelationalDatabase or FileDatabase to setDatabase method and the code in DatabaseBrowser will work, because all that DatabaseBrowser will use is IDatabase interface.

Multiple inheritence:

class Car: public Wheels, Engine, FourSeats, Windshield, etc...

This is a "has-a" relationship. A car has wheels, an engine, four seats, a winshield, etc.. Works well until programmers do this:

class Bus extends Car.

Sounds good, until we realize that we're stuck because the Car programmer only defined a car as being a four-seater.  A Bus has more than four seats. So in C++, it's not unusual to see classes that inherit stuff it doesn't want because the subclass use multiple inheritence the wrong way.

Aggregation

class Table {
}
class Glass {
}

public MyTable extends Table
   public Glass getGlass();
}

Here you define the glass type (clear, shaded, etc..) in an inner class that could be something like MyTableGlass. That is a typical example of aggregation. In C++ you would say:

class MyTable: public Table, Glass;

but then you would have to define Glass in MyTable, where as with aggregation you can create the MyTableGlass class and define it outside of MyTable.

Need some aspirin? :)

Fab.

Reply via email to