Quote:
Originally Posted by Aaron
Why would you need to extend something, would you need to extend it to access a public function, why private functions, why protected, why does nobody use protected, what is implements, why would you need to implement something. How do you know that something doesn't belong in the class you are developing (like, a USER class that pretty much uses nothing but the database)
|
All very basic OO concepts. Take a look at some
tutorials, particularly the ones on Java as PHP's current OO implementation resembles Java quite a bit, I think.
Public properties (methods or data) allow access from anywhere in the script, e.g.
PHP Code:
// 'Car' class allows access to it's 'NumberOfDoors' property
$car= new Car();
// show a property in it's default state - allowed
echo $car->NumberOfDoors;
// alter the property - allowed
$car->NumberOfDoors= 3;
// show the property again - allowed
echo $car->NumberOfDoors;
Protected properties only allow access from within the class or any child classes, e.g.
PHP Code:
class Car {
protected NumberOfDoors;
public function __construct() {
$this->NumberOfDoors = 4;
}
}
// this child class can access any protected member
class EconomyCar extends Car {
public function __construct() {
// call the parent constructor and set any defaults
parent::__construct();
// alter the NumberOfDoors for this model - allowed
$this->NumberOfDoors= 3;
}
}
// instantiate
$car= new EconomyCar();
// show the property - not allowed
echo $car->NumberOfDoors;
// alter the property - not allowed
$car->NumberOfDoors = 4;
Private members are only allowed access from within the parent class.
PHP Code:
class Car {
private NumberOfDoors;
public function __construct() {
$this->NumberOfDoors = 4;
}
}
// this child class can access any protected member
class EconomyCar extends Car {
public function __construct() {
// call the parent constructor and set any defaults
parent::__construct();
// alter the NumberOfDoors for this model - not allowed
$this->NumberOfDoors= 3;
}
}
// instantiate
$car= new EconomyCar();
// show the property - not allowed
echo $car->NumberOfDoors;
// alter the property - not allowed
$car->NumberOfDoors = 4;
In general, you should use the least amount of privilege for any property; IMHO it's a good idea to use protected unless you have reason not to. That way the object properties are kept hidden from the user but not to any child classes.
The reason behind all this is the basic OO concept that objects hide (or encapsulate) the data and methods from the outside world and provide an interface to access them. The Car class NumberOfDoors property should be kept hidden from the user; the person using the class API should be given a set of "controls" to work with the object and hide the internal workings away. Here's an example using the same Car class.
PHP Code:
class Car {
protected NumberOfDoors;
public function __construct() {
$this->NumberOfDoors = 4;
}
// public interface to alter the number of doors
// notice how it carefully controls what the user can do
public function SetNumberOfDoors($num) {
if ( is_numeric($num) && $num >= 2 && $num <= 5 ) {
try {
$this->NumberOfDoors= $num;
} catch ( Exception $e ) { }
}
}
// public interface to retrieve the number of doors
public function GetNumberOfDoors() {
return $this->NumberOfDoors;
}
}
// this child class can access any protected member
class EconomyCar extends Car {
public function __construct() {
// call the parent constructor and set any defaults
parent::__construct();
// alter the NumberOfDoors for this model - allowed
$this->NumberOfDoors= 3;
// use the 'setter' to alter the number - allowed
parent::SetNumberOfDoors('3');
}
}
// instantiate
$car= new EconomyCar();
$car->SetNumberOfDoors('4'); // allowed
$car->NumberOfDoors= 4; // still not allowed
echo $car->NumberOfDoors; // again, not allowed
echo $car->GetNumberOfDoors(); // allowed
These are often called 'setters' and 'getters', or in "real" OO speak they're referred to 'accessors' and 'mutators'. They're the public interface to object data.
I hope this helps your understanding. Please note that the class examples shown are untested.
Quote:
Originally Posted by Aaron
Oh, and totally irrelevant to the topic, how can you code in OOP without bloating your stuff to all hell?
|
Not even an issue; all you're doing is altering your process and encapsulating the data with the behavior in a neat little package. It's no different than writing procedural functions and passing data in and out. Frameworks are a different issue, and I can't really comment because I don't use them. I still don't see it as being a problem.