SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    messing with my mind fristi's Avatar
    Join Date
    Feb 2009
    Posts
    292
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    OOPHP class depending on class?

    Hi,

    I was going through all my classes i created, and it seems that they most of depend on other ones.
    For example:

    Template class -> depends on Style class, Database class & RSS class.
    Style class -> depends on Database class

    etc...

    Is this a good way or bad way? In this way I can't for instance give my template class separately... I have been wondering about the idea behind OOP. And it is supposed to be as flexible as possible. But what if some class needs the results of some other object?


    sorry of this seems a noob question.
    To PHP or to Perl, that is the question!
    (Bucket - simpletest) User

  2. #2
    Web Professional
    Join Date
    Oct 2008
    Location
    London
    Posts
    862
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, it is "a good way".

    In some cases (like the database connection class) you can use singleton pattern so that you don't create a new instance of an object every time you need it.

    For example:

    PHP Code:
    /* WRONG - littering global namespace */
    class Style
    {
        public function 
    doSomething()
        {
            global 
    $db;

            
    $db->doStuff();
        }
    }

    /* WRONG - creating new connection every time you call the method */
    class Style
    {
        public function 
    doSomething()
        {
            
    $db = new DB();

            
    $db->doStuff();
        }
    }

    /* GOOD - create connection or fetch if one already exists */
    class Style
    {
        public function 
    doSomething()
        {
            
    $db DB::getInstance();

            
    $db->doStuff();
        }

    Also, make sure you use autoloading so that you don't mess your code with all those require_once calls.

  3. #3
    SitePoint Addict KJedi's Avatar
    Join Date
    Sep 2005
    Location
    Ukraine, Nikolaev
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's no so noob question as you may think
    Yes, OOP's strength is in OOP decomposition, if you break your algorithm into pieces and implement each piece independently, you get excellent OOP design.
    decowski described singleton pattern, it's a good thing to follow, but there are lots of other helpful pattern. However, I'd recommend if you start from learning GRASP principles, all patterns are pased on it. Here are the links: wikipedia and a post on my blog about grasp. You should pay special attention to the following things:

    • Low Coupling
    • High Cohension
    • Protected variations

    Others are important too, but violating these ones will always give you wrong design.
    Basically you should always have in mind some things:

    • If class is separated from others, it should work correctly or give correct and informative errors, not breaking the other application. Actually writing sinething like this is not correct: $this->dbHandler->connection. You should implement method getConnection(), that will return connection. After that you may use other DB wrapers and name $connection as you like, the only thing they all should have in common is getConnection method.
    • If there may be some variations, you should implement each variation as a separate class and provide common interface for all variations (This is Adapter and TemplateMethod patterns, see wikipedia and my post on this also)

    So, in short: yes, dependency is correct, but each class should do only those things it is designed for. Keep them as separated as possible and design carefully, taking into consideration the fact that you may need to replace some class with other implementation - take care of protecting variations where needed However, protecting variations everywhere is not a good thing too. Find you balance.
    IQ RIA - Delivering smart web-applications
    High-quality PHP, Yii, Ruby on Rails, ExtJS, Backbone, EmberJS and jQuery consulting.
    Dashboards, HTML5 and CRM development.
    Request a quote now!

  4. #4
    SitePoint Enthusiast
    Join Date
    Apr 2001
    Location
    London, UK
    Posts
    59
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You should try to keep your classes as loosely coupled as possible.

    In particular, try not to mix your "business logic" with your "view" - For example your Template class should definitely not be coupled with your Database class.

    Researching and get a better understanding of these terms:

    Encapsulation (db stuff shouldn't be in your template class - they are not related at all - you are not encapsulating your classes very well)
    Coupling
    MVC

    That should put you on the right path for better OOP.

  5. #5
    messing with my mind fristi's Avatar
    Join Date
    Feb 2009
    Posts
    292
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    thanks for the quick replies! Sitepoint Members are the greatest!

    I already know about the Singleton and Factory Patterns, So far those are the only 2 I'm using. For instance my Template class (part can be seen over here) is a singleton because I don't want more template objects being created.

    there is a DB object going to my template class (passed as reference) to get some info from the db and build a certain list I display on every page. So I thought it would be the easiest way to do. Looking at the theory of separating view and logic I maybe should create that list outside of the Template class and pass it as an argument... so the dependence to the db is gone.
    The dependence to the other two classes (style and RSS) has to do with the headers and footers... maybe I also should generate that info in the script itself and pass it as an argument to build the page itself... That way the Template class becomes complete stand alone.
    To PHP or to Perl, that is the question!
    (Bucket - simpletest) User

  6. #6
    SitePoint Addict KJedi's Avatar
    Join Date
    Sep 2005
    Location
    Ukraine, Nikolaev
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I really advice you to start learning some pure OOP (PHP5) frameworks. Most of them are carefully designed and hold good pieces of code and solutions. I chose Yii for me, but you can go with ZendFramework, Symfony, Kohana and many others. See how I was selecting a framework for myself: http://programmersnotes.info/2009/02..._of_my_choice/

    Sorry, folks, I'm not spamming and advertising my blog here, I just have some info there, that is really relevant to discussion!
    IQ RIA - Delivering smart web-applications
    High-quality PHP, Yii, Ruby on Rails, ExtJS, Backbone, EmberJS and jQuery consulting.
    Dashboards, HTML5 and CRM development.
    Request a quote now!

  7. #7
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,042
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by fristi
    there is a DB object going to my template class (passed as reference) to get some info from the db and build a certain list I display on every page. So I thought it would be the easiest way to do. Looking at the theory of separating view and logic I maybe should create that list outside of the Template class and pass it as an argument... so the dependence to the db is gone.
    The dependence to the other two classes (style and RSS) has to do with the headers and footers... maybe I also should generate that info in the script itself and pass it as an argument to build the page itself... That way the Template class becomes complete stand alone.
    The lifespan of the database connection should end once the view is rendered. The exception is when the view indirectly communicates with the database through a model. However, other then that all the appropriate information should have been made accessible to the view before painting it on screen. The views primary responsibility is to display information not retrieve it.

  8. #8
    messing with my mind fristi's Avatar
    Join Date
    Feb 2009
    Posts
    292
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    The lifespan of the database connection should end once the view is rendered. The exception is when the view indirectly communicates with the database through a model. However, other then that all the appropriate information should have been made accessible to the view before painting it on screen. The views primary responsibility is to display information not retrieve it.
    I like that last sentence, that makes it very clear Thanks for that!


    EDIT:

    Quote Originally Posted by KJedi View Post
    I really advice you to start learning some pure OOP (PHP5) frameworks. Most of them are carefully designed and hold good pieces of code and solutions. I chose Yii for me, but you can go with ZendFramework, Symfony, Kohana and many others. See how I was selecting a framework for myself: http://programmersnotes.info/2009/02..._of_my_choice/

    Sorry, folks, I'm not spamming and advertising my blog here, I just have some info there, that is really relevant to discussion!
    At this point I'm not a fan yet of frame works, I prefer to get the hang of PHP itself before I move on to frameworks. But thanks for the tip
    To PHP or to Perl, that is the question!
    (Bucket - simpletest) User

  9. #9
    SitePoint Addict KJedi's Avatar
    Join Date
    Sep 2005
    Location
    Ukraine, Nikolaev
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fristi View Post
    At this point I'm not a fan yet of frame works, I prefer to get the hang of PHP itself before I move on to frameworks. But thanks for the tip
    I did the same, I even wrote my own framework. But then it turned out, that it's more interesting to take advantage using well-designed frameworks, than spend time reinventing the wheel

    But it's up to you. I think, the sooner you move to frameworks - the better. But choose the one to use wisely.
    IQ RIA - Delivering smart web-applications
    High-quality PHP, Yii, Ruby on Rails, ExtJS, Backbone, EmberJS and jQuery consulting.
    Dashboards, HTML5 and CRM development.
    Request a quote now!


Bookmarks

Posting Permissions

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