objects,inheritance and insane abstraction

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
hi list,

i'm trying to lose some bad programming habits and write neat
and re-useable oo php5 code. At the moment i'm trying to write
a highly abstracted interface to ldap (just for fun) and I am not
sure if the way i'm proceeding  is indeed the correct and sane way.

the way i see it, to accomplish the level of abstraction that i want,
i'll need objects like the following :
phpLdap(superclass), phpldapConnection, phpldapRecord, etc etc

<psuedo-ish code>

class phpLDAP {  // a superclass ???
     private $conn = NULL;
     public $search;

     function __construct ($someparms) {
        // hand it of to a different class
    $this->conn = new phpLDAPConnection($someparms);

     function search($someparms) {
         // hand this of to another class
    $this->search = new phpLDAPSearchObject($someparms);

class phpLDAPConnection {
    public $conn = NULL;

    function __construct($someparms) {
            // do ldap connection stuff

    /** more stuff **/

    function __destruct() { }

class phpLDAPSearchObject {

    private $rawResult = NULL;
    public  $records = NULL;

    function __construct($someparms) {
            // search stuff
            foreach($result as $searchResults) {
                $this->records[z++] = new phpLDAPRecord($result);


</psuedo-ish code>

okay, above is a small piece of code example showing how i'm
connecting objects together.

the end result of all this should be being able to do something
like this :


$ldap = new phpLDAP($someparms);

if ($ldap->conn->Connected) {    // property of phpLdapConnection
  $ldap->search($someparms);   // do a search

  $search = &$ldap->search;

  do {
            // returns for ex: a phpLDAPRecord
           $curRec = &$search->ActiveRecord;

            // a method of a phpLDAPRecord

            // a property of a phpLDAPSearch
           echo $search->count;

             // a method of a phpLDAPSearch
           echo $search->refresh();

              // method of phpLDAPSearch

  } while (!($search->BOF));
// etc etc
} // endif


I hope that what i'm trying to do is clear. I would like to now if
this is the correct way to do abstraction or if i'm missing the
plot completely.  


Re: objects,inheritance and insane abstraction

intrupt000@gmail.com wrote:

Quoted text here. Click to load it

Just for the sake of adding some balance to any conversation that might
arise, many people believe that adopting too much OO is a worsening of bad
habits.  It reveals itself in exactly the words you are using, "insane

There's a great satire (that I could not find on Google) about an
"advancing" computer programmer.  As a beginner his Hello World! programs
take 2-3 lines.  As he gets smarter and smarter they get larger and larger,
until it takes pages of OO-abstracted deeply nested hierarchies of objects
just to get a gol'darn Hello World! onto the page.  Very sobering stuff.

Kenneth Downs
Secure Data Software, Inc.

Re: objects,inheritance and insane abstraction

Kenneth Downs wrote:
Quoted text here. Click to load it

Hehe. I call it the Emperor's New Coat syndrome. Even when it's plain
to see that there is not need to wrap something in a class, people do
it anyway because they're afraid that others will say they're stupid.

Re: objects,inheritance and insane abstraction

Quoted text here. Click to load it

This is the opposite (but similar) to what I called the "Name That Tune"  
syndrome in the early days of C programming.  Whiz kids would compete to see  
how few lines they could use to write a For loop, for example.  Often, when  
for readability and debugging the code should have been 10 lines, it was  
written as one line by some smartass, show-off programmer.


Re: objects,inheritance and insane abstraction

Shelly wrote:
Quoted text here. Click to load it

One has to make a distinction between syntactical complexity and
analystical complexity. The human brain is very good at decoding
syntax. It's part of our innate capability to process language. Whereas
we're much more limited when it comes to solving analystical problems.
If you look at entries into the the Obfuscated C contest, for example,
you'll always find that their difficulty arises from twisted
logics--not strange syntax.

I am, of course, not arguing for hard to read code. I am just saying
that adding unnecessary structural complexity to a program is a far
greater sin. You can always clean up ugly code. You can't really fix an
overly complicated framework because your brain cannot fully understand

Site Timeline