Jump to content

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


matthewhaworth

Recommended Posts

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;
    }
}
?>

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • 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.