SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 42
  1. #1
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why is an OOP class called a 'class'?

    Why is an OOP class called a 'class'?

  2. #2
    SitePoint Wizard jimbo_dk's Avatar
    Join Date
    May 2005
    Location
    Singapore
    Posts
    1,261
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't really know the answer to that, but I'm assuming because it's a sort of classification? Why do you want to know anyways?
    Winners Respond. Losers React.
    Singapore Web Designer

  3. #3
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'anyway' is the word.
    Why? I don't like to work with things that mean nothing to me.

  4. #4
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Think of it as classification - a variable has a certain classification, therefore does certain things.

    Personally I would have called it "object" or something - and called interfaces 'class'.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  5. #5
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The name class hints at the difference between the abstract concept and a concrete instance of that concept. In OOP, a class is never used directly. Instead, you create instances (Objects), which belong to a class. So you can think of class as a generic type, while the object is a concrete example of that type. Sort of like the word "horse" identifies all horses in the world, past and present, while Jolly Jumper is a concrete instance of said type.

  6. #6
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've got a lot of work ahead of me! I am using a reasonably complex OOP application with very little commenting. At the moment, it's still quite opaque to em!

  7. #7
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    How much experience do you have with OOP?
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  8. #8
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bgsomers View Post
    I've got a lot of work ahead of me! I am using a reasonably complex OOP application with very little commenting. At the moment, it's still quite opaque to em!
    "me" is the word.


  9. #9
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    "me" is the word.

    You're right of course.

  10. #10
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Oop

    How much experience do you have with OOP?

    Very little. This guestbook application is my first introduction to it.

    I've been able to introduce some tests to exclude rubbish. I have great difficulty in following the flow of execution. The code is essentially without comments.

  11. #11
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    What does it do?

    If I have

    include("config.php");
    $this->indexsize = $indexsize;
    $this->entriesperpage = $entriesperpage;

    Does this make the values of $indexsize and $entriesperpage from config.php available in all instances of the current class? Or only within the current instance (object)?

  12. #12
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    $this is used to refer to a particular instance of a class. It makes no sense to use $this outside the scope of a class method.

    PHP Code:
    class Product {
        var 
    $name;
        function 
    Product($name) {
            
    $this->name $name;
        }
        function 
    getName() {
            return 
    $this->name;
        }
    }

    $a = new Product('A');
    $b = new Product('B');

    echo 
    $a->getName() . ' ' $b->getName(); 
    output will be "A B"

    That's PHP4-ish style code. Static class variables (i.e., values that are shared across instances of the same class) aren't available there, but they are available in PHP5.

    I'd suggest reading the manual and searching for some tutorials on the basics of OOP in PHP5.

  13. #13
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    include("config.php");
    $this->indexsize = $indexsize;
    $this->entriesperpage = $entriesperpage;

    is within a function (method?) of a certain class. Must it not be avaiiable within all instances (objects?) of that class?

  14. #14
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yep, a function in a class is known as a method in OO parlance.

    Anything accessed through the $this variable is bound to a particular instance of a class, which is exactly what the special $this variable signifies.

    Variables shared across instances of a class are known as static class variables. PHP4 did not support these, but PHP5 does.

    PHP Code:
    class Product {
        private 
    $name;
        private static 
    $textTemplate 'this is product %s';
        public function 
    __construct($name) {
            
    $this->name $name;
        }
        public function 
    getText() {
            return 
    sprintf(self::$textTemplate$this->name);
        }
    }

    $a = new Product('A');
    $b = new Product('B');

    echo 
    $a->getText() . ', ' $b->getText(); 
    Will output "this is product A, this is product B"

    That will only work in PHP5 obviously.

  15. #15
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cuberoot View Post
    Variables shared across instances of a class are known as static class variables. PHP4 did not support these, but PHP5 does.
    The fact that they are there doesn't mean that you should use them though. So better just forget that you read that last post.

  16. #16
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It makes no sense to use $this outside the scope of a class method.

    But if it is used within a method belonging to a certain class, must it not refer to all instances of that class?

  17. #17
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm, umm, let me think about that a minute... uhhm, no. Nope. NOOO!

    Think of it this way...

    PHP Code:
    class Person {
        private 
    $confusedAboutOOP;
        public function 
    __construct($confused) {
            
    $this->confusedAboutOOP $confused;
        }
        public function 
    talkAboutOOP() {
            if (
    $this->confused) {
                echo 
    'Wait, wait, wait... $this is shared across instances, right?';
            } else {
                echo 
    'no. Actually... no. NOOOOO!';
            }
        }
    }

    $bgsomers = new Person(true);
    $cuberoot = new Person(false);

    $bgsomers->talkAboutOOP();
    $cuberoot->talkAboutOOP(); 
    If $this was shared across instances, both of us would be confused or both of us would understand. However, that is not the case.

    A class describes the properties something has in abstract terms, but an instance describes them concretely. For example, every person has a height attribute, but the height of each individual will vary.

  18. #18
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Ok, time for some OOP basics.

    • A class is practically a set of variables and methods.
    • An object is a variable which uses the instructions (vars and methods) laid out by the class.
    • You use the "->" operator to access variables and methods from an object:
      • If you are outside the object, use the variable name. For example, if the variable holding an object is $a, use $a->function().
      • If you are in the class code block, the object doesn't exist yet. So you use '$this' to tell the object that it is refering to itself, no matter it's variable name - however, it does not affect the other objects using that class, unless they run that function.
    • Static variables are those which are the same for all instantiations of a class. These use the '::' operator to access them. Instead of '$this', it is called 'self', referring to all objects in that class. Outside of that class, it's refered to by the class name, e.g. class_name::$var = 'hello'. Note that you keep the dollar sign for the variable.
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  19. #19
    Theoretical Physics Student bronze trophy Jake Arkinstall's Avatar
    Join Date
    May 2006
    Location
    Lancaster University, UK
    Posts
    7,062
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Cuberoot - a typo, I hope.

    Should be:
    PHP Code:
    class Person {
        private 
    $confusedAboutOOP;
        public function 
    __construct($confused) {
            
    $this->confusedAboutOOP $confused;
        }
        public function 
    talkAboutOOP() {
            if (
    $this->confusedAboutOOP) {
                echo 
    'Wait, wait, wait... $this is shared across instances, right?';
            } else {
                echo 
    'no. Actually... no. NOOOOO!';
            }
        }
    }

    $bgsomers = new Person(true);
    $cuberoot = new Person(false);

    $bgsomers->talkAboutOOP();
    $cuberoot->talkAboutOOP(); 
    Jake Arkinstall
    "Sometimes you don't need to reinvent the wheel;
    Sometimes its enough to make that wheel more rounded"-Molona

  20. #20
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ha! Good save.

  21. #21
    SitePoint Enthusiast
    Join Date
    Nov 2005
    Posts
    45
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    # You use the "->" operator to access variables and methods from an object:

    * If you are outside the object, use the variable name. For example, if the variable holding an object is $a, use $a->function().
    * If you are in the class code block, the object doesn't exist yet. So you use '$this' to tell the object that it is refering to itself, no matter it's variable name - however, it does not affect the other objects using that class, unless they run that function.

    # Static variables are those which are the same for all instantiations of a class. These use the '::' operator to access them. Instead of '$this', it is called 'self', referring to all objects in that class. Outside of that class, it's refered to by the class name, e.g. class_name::$var = 'hello'. Note that you keep the dollar sign for the variable.

    Thanks arkinstall -- clearest explanation I've seen to date

  22. #22
    SitePoint Zealot
    Join Date
    Feb 2008
    Posts
    109
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    The fact that they are there doesn't mean that you should use them though. So better just forget that you read that last post.
    No valid use cases whatsoever?

    DM

  23. #23
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DangerMouse1981 View Post
    No valid use cases whatsoever?
    The ones I can think of are either very exotic or are optimisation techniques. Sometimes performance is crucial, but it's usually a tradeoff against good design, so it shouldn't be applied until absolutely needed.

  24. #24
    SitePoint Addict
    Join Date
    Feb 2007
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What do you think about the following transaction script approach from "PHP5 Objects, Patterns, and Practice" --

    PHP Code:
    abstract class DbLogic {
        private static 
    $db;
        private static 
    $stmts = array();
        public function 
    __construct(PDO $db) {
            
    self::setDbConnection($db);
        }
        public 
    setDbConnection(PDO $db) {
            
    self::$db $db;
        }
        protected function 
    prep($sql) {
            if (
    self::$stmts[$sql]) {
                return 
    self::$stmts[$sql];
            }
            
    self::$stmts[$sql] = self::$db->prepare($sql);
            return 
    self::$stmts[$sql];
        }
        protected function 
    exec($sql$data null) {
            
    $stmt $this->prep($sql);
            
    $stmt->execute($data);
            
    // throw some exceptions here...
            
    return $stmt;
        }
    }

    interface 
    IThingLogic {
        public function 
    addThing($data);
        public function 
    getThings();
    }

    class 
    ThingLogic extends DbLogic implements IThingLogic {
        public function 
    addThing($data) {
            return 
    $this->exec('INSERT INTO things (name) VALUES (:name)'$data);
        }
        public function 
    getThings() {
            return 
    $this->exec('SELECT * FROM things');
        }

    I'm not sure what you gain by caching the prepared statements in static class variables, since you could obviously cache them in instance variables just the same. I can't imagine having more than one instance of ThingLogic running at any given time, so this design choice feels a bit arbitrary.

    Does this qualify as a poor design choice? If so, what makes it so? What do you lose with this approach?

  25. #25
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cuberoot View Post
    I'm not sure what you gain by caching the prepared statements in static class variables, since you could obviously cache them in instance variables just the same. I can't imagine having more than one instance of ThingLogic running at any given time, so this design choice feels a bit arbitrary.
    Presumably, there would be a multitude of classes derived from DbLogic. Some of these might utilise the same queries, so since preparing a statement costs some calculations, there would be a slight performance gain by sharing it across classes.

    Quote Originally Posted by cuberoot View Post
    Does this qualify as a poor design choice? If so, what makes it so? What do you lose with this approach?
    I think so, for a number of reasons. First off, this is premature optimisation. Sure, there is some waisted clock-cycles, but those are most likely a drop in the ocean anyway. One shouldn't employ optimisation techniques before there is a proven bottleneck.

    Secondly, this is using inheritance for something that is more aptly solved with composition. A much better solution would be to create a query-cache wrapper as a decorator to the database-connection. That would make the ThingLogic's implementation simpler and would make it easier to replace (Or introduce in the first place) the caching-behaviour, should that be needed.


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
  •