Jump to content

[SOLVED] Do implement db.class twice? Or can an implemented object use resources from..


matthewhaworth

Recommended Posts

Do implement db.class twice? Or can an implemented object use resources from the object it's implemented into?

 

Context?

 

Can image.class use functions from db.class once it's implemented into user.class?

 

l_cba9c4402e0292ce2e8d584fe5bf9b94.jpg

interface defines a template of functions (and in languages other than PHP, return values)

 

UserManagement (Factory) just instantiates User objects. User objects should contain an instance of the Database layer you want to use.

 

<?php

class User {

    private /*(UserDAO)*/ $dao;
    
    function User($name) {
        $this->dao = new UserDAO();
        $this->name = $name;
    }
}
?>

interface defines a template of functions (and in languages other than PHP, return values)

 

UserManagement (Factory) just instantiates User objects. User objects should contain an instance of the Database layer you want to use.

 

<?php

class User {

    private /*(UserDAO)*/ $dao;
    
    function User($name) {
        $this->dao = new UserDAO();
        $this->name = $name;
    }
}
?>

 

What do you mean by the database layer? I don't get what your code, DAO Data Access Objects, what're they?  Is it my database class being passed to my classes instead of implemented?

Also note, that the factory does more than just pass objects, it performs registration and login (it's the login function that passes the object)... it's never initiated.

Lets take first the whole idea behind why you take OOP design over a procedural design. The biggest reason is encapsulation and the next is maintenance. A DAO encapsulates the retrieval of data for a certain object or service, to make it function.

 

Take this example:

 

<?php
//first a bad example:
class User {
   .
   .
   . // all other methods

   function getSomeData() {
         $data = mysql_query("select someData from users where username = ..........");
         //loop through retrieve data, or whatever
   }
}

//and a 'better' example
class User {
   .
   .
   . // all other methods

   function getSomeData() {
        try {
             return UserDAO->fetchData();
        catch (SomeUserException $sue) {
              // could not get data, do some error handling.
             return false;
        }

   }
}

 

This way, UserDAO can switch between Postgres, MySQL, SQLite, Oracle.. who cares, your user object manages just the user data, and you get the data from an object whose sole purpose is to get data.

 

Lets take first the whole idea behind why you take OOP design over a procedural design. The biggest reason is encapsulation and the next is maintenance. A DAO encapsulates the retrieval of data for a certain object or service, to make it function.

 

Take this example:

 

<?php
//first a bad example:
class User {
   .
   .
   . // all other methods

   function getSomeData() {
         $data = mysql_query("select someData from users where username = ..........");
         //loop through retrieve data, or whatever
   }
}

//and a 'better' example
class User {
   .
   .
   . // all other methods

   function getSomeData() {
        try {
             return UserDAO->fetchData();
        catch (SomeUserException $sue) {
              // could not get data, do some error handling.
             return false;
        }

   }
}

 

This way, UserDAO can switch between Postgres, MySQL, SQLite, Oracle.. who cares, your user object manages just the user data, and you get the data from an object whose sole purpose is to get data.

 

 

I think I understand, but you haven't answered my question.. hmm, could you do me a quick diagram of your structure?

 

http://en.wikipedia.org/wiki/Data_Access_Object

 

Yes it is my database class you were referring to, I can now review my design and pass it an object instead of implementing it.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.