In developing several classes (or should it be interfaces?) related to a specific kind of computing operation, such as interacting (or again, is it interfacing?) with a filesystem or with a MySQL database, all of these classes will have an organic relationship.
For instance, I have a single file, MySQLDatabase.Class.php which contains several classes:
class MySQLDatabase // describes properties/methods of a server with several databases
class DatabaseRoot // the starting point in the tree for all databases
class Database
class Table
class Field
class FieldCharacteristics
class ResultRecord
I have another set of files, each with a single class in its own file:
class DirectoryEntry // in DirectoryEntry.Class.php
class DirectoryTree // in DirectoryTree.Class.php
class PathList // in PathList.Class.php
I think it is clear about these class relationships: for databases, fields make up tables, tables make up databases, and databases make up a single root of databases which describe the server.
For file systems, a directory entry can be a file, (sub)directory, (symbolic) link, and so on. A directory tree would be a branch of the file system, with a recursive description of all its files and of subdirectories and their files. The "path list" class is really a list of files of interest, each file with its fully qualified path name (or even URL?): they might be used as a list of files to be synchronized between the filesystems of two hosts in which synchronization uses ftp.
But in my programming, no one class extends another.
DirectoryTree is not extended by DirectoryEntry, although instances of DirectoryEntry are contained by DirectoryTree perhaps in a property that is an array of these objects.
A Tableobject contains a property which is an array of Fieldobjects which describe the table. A Databaseobject contains a property that is an array of Tableobjects that describe it.
But despite these relationships, it is not necessary to extend the containing class by the class that is contained (base class?).
Or is it? Can it be done? Should it be done? Is it demanded by the philosophy of object-oriented programming? It does not seem obvious to me.
Last edited by mavigozler; 11-10-2010 at 01:36 AM.
It is indeed demanded by the philosophy of object-oriented programming and how to work with objects and relationships.
Basically you use extend if you have a "is a" relationship between two objects. In Object-Oriented programming terms this is called inheritance.
To give a more real life example we can have the class Car and the class Bus. Both of these have attributes and functionality that are similar. Thus they could both extend the class Vehicle which is a more generic type but can still be attributed to both Car and Bus.
So all the common functionality would end up in the Vehicle class and all the Car and Bus specific functionality would end up in the respective classes.
When you have the relationship of "has a" then you have what you describe. You Table has Field:s so in your table class you have an array of Field:s. This is perfectly alright. In Object-Oriented programming terms it is called aggregation.
I would say that it would most likely be wrong for your to have extend in any of your class relationships because you do not have an inheritance relationship between your objects.
Another thing to look for which may or may not apply here are any classes that, in part, do similar things. This may be a case for implementing interfaces. For instance, it may be that one of your database-related classes and one of your filesystem-related classes provide a similar tree structure, and you want to include methods for traversing the tree. This might be a case for a Tree interface, which would define the common method names to be used. Then you can be assured that both classes have a common interface for traversing their trees, even if the detailed execution is quite different -- but transparent to the client code.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Slightly OT but i like to have one file one class.
Any thoughts on that?
This is how I do it, too, and is probably the norm. This allows you to only load class definitions that you need, and makes it easier to re-use any given class with another package/application. With a consistent directory structure and naming conventions, you can use an __autoload() function to make the loading of them essentially transparent to your application code, too.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Reply With Quote
Originally Posted by Belrick
Bookmarks