Examples I read of class structure typically begin with a base class and that base class gets extended with more refined classes ie. the often quoted:
class Animal {}
class Rodent extends Animal {}
class Mouse extends Rodent {}
But in my real world project of a CMS/ecommerce system I seem to be building this structure the other way around i.e. starting with a class for one type of situtation and extending it with something related to the whole project but not actually to the extending class.
class page {}
class product extends page{}
class category extends product{}
class basket extends category{}
class shop extends basket{}
So this way I am just calling $s = new shop() and getting access to all the classes/methods needed to run the shop. I suppose I am just extending the classes to save instantiating each one separately. This seems backwards to most examples I have read and I'm surely missing what OOP is all about here. My classes seem to be getting more general and less specialised as they get extended.
Should I continue in this way or restructure how I am building this class system?
You could google composition over inheritance and is-a vs has-a.
In your design sketch, you mix up a bunch of stuff as you noticed. The easiest example to dissect would be class category{} extends product. One category is not a product, but it has/contains several products. This would be more suitable:
class product {
public $title; // for simplicity
public $price; // for simplicity
}
class category {
private $name;
private $products;
public function __construct($name) {
$this->name = $name;
$this->products = array();
}
public function addProduct(product $p) {
$this->products[] = $p;
}
public function printProducts() {
$product_names = array_map(function($product) {
return $product->title;
}, $this->products);
echo implode(', ', $product_names);
}
}
$c = new category('fruits');
$apple = new product;
$apple->title = 'apple';
$orange = new product;
$orange->title = 'orange';
$banana = new product;
$banana->title = 'banana';
$c->addProduct($apple);
$c->addProduct($orange);
$c->addProduct($banana);
$c->printProducts();
Notice how you keep both entities separated and let product worry about what a product is and can do, and what a category is (name), has (products) and can do (print a listing of its products).
Another tip for decoupling (minimizing dependencies between classes) is that you should try to keep data out of your objects for as long as possible. The classes in the example above are simplistic but functional. If you can make them work without database access (which is a common reason to have a huge chain of extends), you realize that none of these classes needs database access and that they instead can be filled/created by classes that do have access to the database. Something like this:
class category_factory {
public function __construct(PDO $pdo) { $this->pdo = $pdo; }
public function getCategories() {
$rows = $this->pdo->query("SELECT * FROM categories")->fetchAll();
$categories = array();
foreach($rows as $row) {
$categories[] = new category($row['name']);
}
return $categories;
}
}
*PDO contains a db connection
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With