php class with predefined rules for object attributes - php

Question

I'm often coming along with the following case and I'm not sure if it's a good practice in OOP. So I thought maybe you can help me with this.
I'll simplify this with an example of adding fruits to a fruit basket, like this:
$obj = new FruitBasket();
$obj->add(new Fruit('Banana'));
$obj->add(new Fruit('Apple'));
$obj->add(new Fruit('Kiwi'));
$obj->get();
The class "FruitBasket" simply adds and outputs the data:
class FruitBasket {
private $fruits = [];
public function add(Fruit $fruit)
{
$this->fruits[] = $fruit;
}
public function get()
{
foreach ($this->fruits as $fruit)
{
echo $fruit->get('type') .': '. $fruit->get('color') .' with '. ($fruit->get('seed') === true ? 'seeds.' : 'no seeds.') . '<br>';
}
}
}
Ok.
Then the "Fruit" class — this is where I'm thinking of a better practice:
class Fruit {
private $type;
private $color;
private $seed;
// Is this cool(?):
private $rules = [
'Apple' => ['color' => 'red', 'seed' => true],
'Banana' => ['color' => 'yellow', 'seed' => false],
'Kiwi' => ['color' => 'green', 'seed' => true]
// …
];
public function __construct($type)
{
if (isset($this->rules[$type]))
{
$this->type = $type;
$this->color = $this->rules[$type]['color'];
$this->seed = $this->rules[$type]['seed'];
}
}
public function get($attr = null)
{
if (isset($this->$attr) && !is_null($this->$attr))
return $this->$attr;
}
}
This class (Fruit) contains an attribute $rules, which is an array of all possible (or "allowed") fruits. In this example there are only 3 of them, but in real world they could also be up to 20. Well. This array also contains attributes for each fruit. Attributes that won't ever change, because a banana always will be yellow (let's say so). So these attributes are constants.
When the Fruit-object is created, the constructor sets all these attributes.
So my question is: Is it good to have this array of possible fruits and their attributes?
…
I wrote an alternative version of the Fruit class AND classes for each type of Fruit. See it here:
abstract class Apple {
const color = 'red';
const seed = true;
}
abstract class Banana {
const color = 'yellow';
const seed = false;
}
abstract class Kiwi {
const color = 'green';
const seed = true;
}
// …
class Fruit {
private $type;
private $color;
private $seed;
public function __construct($type)
{
$class = $type; // just to make it clear
if (class_exists($class))
{
$this->type = $type;
$this->color = $class::color;
$this->seed = $class::seed;
}
}
public function get($attr = null)
{
if (isset($this->$attr) && !is_null($this->$attr))
return $this->$attr;
}
}
These classes are set to "abstract" because I don‘t want to create objects from them. (I know(!) that I could extend those Fruit-Classes with the Fruit-Class, but this doesn't work in every case and isn't the point here.)
What I also don't like about this (2nd) version is, that I need to create own files for each fruit (when using autoload …).
So if I compare writing up to 20 classes for each fruit plus putting them into 20 separate files WITH a simple array … well … the array is so simple.
But what i want to know is … is there any "best practice" for this problem?
Any pattern? What would you suggest?

Answer 1

Given that both methods work, it comes down to readability and practicality. I personally find the first method more user friendly. You can easily see the relationship between the fruit and it's properties in the array given.
The only problem I might see is that the class might get too big with the addition of more properties, and could dwarf the other variables and functions in the Fruits class. You could alternatively create another class for storing the rules:
class Rules {
protected $rules = [
'Apple' => ['color' => 'red', 'seed' => true],
'Banana' => ['color' => 'yellow', 'seed' => false],
'Kiwi' => ['color' => 'green', 'seed' => true]
// …
];
}
and then have your fruit class extend it:
class Fruit extends Rules {//...
This would give you 2 benefits:
Cleaner code.
If for some reason in the future you need these rules in another class, you can simple extend it as well.