Why is an OOP class called a 'class'?

[bgsomers]

Why is an OOP class called a 'class'?

[jimbo_dk]

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?

[bgsomers]

'anyway' is the word.
Why? I don't like to work with things that mean nothing to me.

[Jake Arkinstall]

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'.

[kyberfabrikken]

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.

[bgsomers]

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!

[Jake Arkinstall]

How much experience do you have with OOP?

[cuberoot]

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.

[bgsomers]

"me" is the word.

You're right of course.

[bgsomers]

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.

[bgsomers]

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)?

[cuberoot]

$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.

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.

[bgsomers]

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?

[cuberoot]

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.

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.

[kyberfabrikken]

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.

[bgsomers]

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?

[cuberoot]

Hmm, umm, let me think about that a minute... uhhm, no. Nope. NOOO!

Think of it this way...

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.

[Jake Arkinstall]

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]

Cuberoot - a typo, I hope.

Should be:

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(); 

[cuberoot]

Ha! Good save.

[bgsomers]

# 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

[DangerMouse1981]

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

[kyberfabrikken]

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.

[cuberoot]

What do you think about the following transaction script approach from "PHP5 Objects, Patterns, and Practice" --

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?

[kyberfabrikken]

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.

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.