[RESOLVED] OOP & Dependencies

[leatherback]

I have only recently restarted programming moving from PHP4. into 5. and with this started working on OOP so please be gentle 😉

I am trying to get my head around separating classes and making sure code becomes independent.

So, when I have a class institute that gets information from a database, I would have to inject institute with an instance of the database class, right?:

e.g.

$dbh = new database();
$a = new institute();

$a->SetDBI($dbh);

In database class, I have a method pulling one record from the database, and is fed with the table table, the ID-coloum and the actual ID of the record to be pulled.

Now, say I want one method in Institute that gets one institute. To me it would make sense to then use the database class method getone():

public function GetInstitute()
    {
    $record = $this->dbi->GetOneRecord('table', 'coloum', $this->id);
    }

Is this the right way of going about it? It feel that I am still building dependencies between classes this way?
It feels that GetInstitute should not know anything about the database it is using. However, at some point a class has to know something about the outside world? Or would one create a class that gives the name of the sortcolom for specific tables, and table names to specific classes?

How is this done in practice? I find a lot of theory, and some CI classes; which feel like way to complex. Is there a middle ground for small, one-coder projects?

Kind-a stuck on the best approach

[NogDog]

I would probably make the database object a parameter of Institute::construct(). That way (a) you have to pass it in or you get an exception, and (b) it becomes part of the Institute class's prototype, making the dependency immediately clear to anyone trying to use it. Also, you can use type-hinting to make it explicit what's expected:

class Institute
{
  private $dbi;
  public function __construct(PDO $pdo) // change type-hint if not PDO
  {
    $this->dbi = $pdo;
  }
}

$dbh = new Database();
$inst = new Institute($dbh);

[leatherback]

Hi,

thx for that. Will try.

How about this:

$record = $this->dbi->GetOneRecord('table', 'coloum', $this->id); 

Would it be better to define a class say, DatabaseArchitecture that can: getTableName("Institutes"), GetAllColumNames($table), GetColumNames($NeededColumsArray, $table), GetIDColum($table) or would that make the application needlesly complex?

[Weedpacket]

As well as NogDog's observations; (c) It ensures that if you have an Institute object then it is a functioning Institute object, with one less step to take before it can be used (a step which might be missed by accident, leading to an error much later on).

[leatherback]

Thx Weedpacket.

Any thoughts on the second part? How to deal with table information?

[traq]

leatherback;11035939 wrote:

Is this the right way of going about it? It feel that I am still building dependencies between classes this way?
It feels that GetInstitute should not know anything about the database it is using. However, at some point a class has to know something about the outside world? Or would one create a class that gives the name of the sortcolom for specific tables, and table names to specific classes?

Classes only need to know enough about the "outside world" to interact with it. An API: a set of methods that do things and are intended to be used to interact with other objects.

You're right that [font=monospace]getInstitute[/font] shouldn't know anything about the database - things like the table name or column name should not be there.

All that [font=monospace]getInstitute[/font] needs to know is:

• there is a method called [font=monospace]GetOneRecord[/font].

• the [font=monospace]GetOneRecord[/font] method needs a record id.

• the [font=monospace]GetOneRecord[/font] method returns a record that matches the given id.

It doesn't matter at all how [font=monospace]GetOneRecord[/font] gets the record. Could be from a database, could be hard-coded in the method definition. Could be made up on the fly. As long as [font=monospace]getInstitute[/font] know how to use the method, how it works is not important.

edit

<?php

class institute{

public function __construct( recordStorage $storage ){
    $this->storage = $storage;
    $this->id = 1;
}

public function getInstitute(){
    $record = $this->storage->GetOneRecord( $this->id );
    //  . . . 
}
}

// (for example)
class recordStorage extends PDO{

//  . . .

public function GetOneRecord( $id ){
    $result = $this->query( "SELECT ... WHERE `id`=$id", );
    //  . . .
}
}

To clarify, [font=monospace]GetOneRecord[/font] does not return a PDO result set. It returns a regular PHP data structure (perhaps an object or associate array) that [font=monospace]getInstitute[/font] can use right away, without having to do any processing or having to worry about how it is/was stored in the DB.

If you later find you need to change the query, you can, as long as you don't change what arguments [font=monospace]GetOneRecord[/font] needs or what values it returns. You could even substitute a different [font=monospace]recordStorage[/font] class that doesn't use a database at all.

[leatherback]

So, if I get this right, if I want to avoid all database interaction, I need to define classes that can take the right table to use (sloppy coding below; I just typed this straight into the phpb editor to verify my understanding of the logic):

class institute{

public function __construct( recordStorage $storage ){
    $this->storage = $storage;
    $this->id = 1;
}

public function getInstitute(){
    $this->storage->setDataSource("Institute");
    $this->storage->SelectByIdField();
    $record = $this->storage->GetOneRecord( $this->id );
    //  . . . 
}
}

// (for example)
class recordStorage extends PDO{

public function setDataSource($Table)
  {
  $this->_currenttable = GetTableName($Table);
  }

public function SelectByIdField()
 {
  $this->_wherefield=($this->GetIdColum($this->_currenttable));
  }

public function GetOneRecord( $id ){
    $result = $this->query( "
               SELECT $this->ColumNames($this->_currenttable, 'ForQuery') 
                FROM  $this->_currenttable 
               WHERE $this->_wherefield =$id", limit);  // naturally, with proper pdo coding
    //  . . .
}
}

[traq]

I think you're understanding the basic idea.

Two paths:

1) IF you intend to have only one [font=monospace]recordStorage[/font] class to serve all other classes, then your [font=monospace]setDataSource[/font] method makes sense. Ideally, however, it would not require the DB table name (as implied here)—instead, just specify the "record type." That way, you can make changes to the DB structure whenever needed, accommodate records that might require more than one DB table to store, and so forth. The [font=monospace]recordStorage[/font] class should be responsible for deciding what the table name is, based on the type of record requested.

Another suggestion would be to pass the record type at the same time as you pass the id:

$record = $this->storage->GetOneRecord( 'Institute',1 );

The way you have it now, there's a risk of forgetting to call [font=monospace]setDataSource[/font] before a subsequent call, which would result in the wrong record (and wrong record type) being returned.

2) If NOT, then the "data source" can be implicit. This is the approach I take. I have a base [font=monospace]storage[/font] class that accesses the database, and I extend that base class for each record type I have. I might end up with something like:

class storage extends MySQLi{
    /* basic database access methods */
}

class instituteStorage extends storage{
    /* methods for accessing institute records */
}

class customerStorage extends storage{
    /* methods for accessing customer records */
}

//  and so forth

Grouping all record storage methods into one class makes more sense at first, but from a practical standpoint, you're going to end up with a BIG class very quickly. Big classes are hard to maintain and easy to be confused by. A single class might work "just fine" for tiny-to-small projects, but separating it all into several smaller classes is definitely the way to go with medium-to-large projects.

[leatherback]

Super. That gets me going for now. Will open another thread in case I run into specific problems.