www.webdeveloper.com
Results 1 to 6 of 6

Thread: Extending Classes: When Is It Obvious?

  1. #1
    Join Date
    Jun 2009
    Location
    Miami
    Posts
    118

    Extending Classes: When Is It Obvious?

    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 Table object contains a property which is an array of Field objects which describe the table. A Database object contains a property that is an array of Table objects 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.

  2. #2
    Join Date
    Sep 2010
    Posts
    160
    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.

    Hope it helped.

    Archie

  3. #3
    Join Date
    Jun 2009
    Location
    Miami
    Posts
    118
    Thanks for the explanation, Archie.

    This "has_a" and "is_a" test is one I will apply to determine the relationship.
    Last edited by mavigozler; 11-10-2010 at 04:24 AM.

  4. #4
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,175
    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

    eBookworm.us

  5. #5
    Join Date
    Apr 2010
    Posts
    227
    Slightly OT but i like to have one file one class.

    Any thoughts on that?

  6. #6
    Join Date
    Aug 2004
    Location
    Ankh-Morpork
    Posts
    19,175
    Quote Originally Posted by Belrick View Post
    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

    eBookworm.us

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles