Hum...
Faire une classe qui possède une méthode acceptant, en entrée, le niveau du bâtiment et qui renvoie la quantité de ressource demandée (donc, 2 classes s'il y a deux ressources)? Avec une interface/classe abstraite par-dessus pour ne pas faire de dépendances en dur (toujours travailler avec une classe abtrasite/interface dans les typehinting et la conception plutôt que des classes réelles).
En version "j'me contente des classes concrètes et zut pour les dépendances, interfaces, extensibilité et combinatoire", on peut ne garder que les classes concrètes "TelBatimentSableCalculator " et "TelBatimentStructureLevel".
Après, la quantité retournée devrait être typée (schématiquement sans tenir compte des dépendances engendrées et en mono-ligne, return new RessourceSableQuantite( pow($this->baseExponent, $p_structureLevel->getLevel() - 1) ); la classe représentant alors une quantité de la ressource "sable").
Si t'as plusieurs fois le même patron de fonction (exemple: n^p +q*p) alors tu peux en faire une autre classe ou une fonction (pourquoi pas pour le coup, c'est logique) et la réutiliser dans TelBatimentSableCalculator.
Faire une classe qui possède une méthode acceptant, en entrée, le niveau du bâtiment et qui renvoie la quantité de ressource demandée (donc, 2 classes s'il y a deux ressources)? Avec une interface/classe abstraite par-dessus pour ne pas faire de dépendances en dur (toujours travailler avec une classe abtrasite/interface dans les typehinting et la conception plutôt que des classes réelles).
<?php
namespace
{
/**
* Représente un calculateur de quantité de sable pour TelBatiment.
*/
interface ITelBatimentSableCalculator
{
public function calculate(ITelBatimentStructureLevel $p_structureLevel);
}
/**
* Calcule la quantité de sable requise pour accéder au niveau indiqué.
* Note: le niveau entré doit être le niveau pour un batiment "TelBatiment"
*/
class TelBatimentSableCalculator implements ITelBatimentSableCalculator
{
protected $baseExponent = 1.6;
public function calculate(ITelBatimentStructureLevel $p_structureLevel)
{
return pow($this->baseExponent, $p_structureLevel->getLevel() - 1);
}
}
/**
* Représente un niveau d'une structure quelconque; on pourrait utiliser un integer directement sinon.
*/
interface IStructureLevel
{
}
/**
* Niveau d'un bâtiment de type quelconque.
*/
interface IBatimentStructureLevel extends IStructureLevel
{
}
/**
* Niveau d'un batiment quel qu'il soit.
*/
abstract class ABatimentStructureLevel implements IBatimentStructureLevel
{
protected $level = 0;
public function getLevel()
{
return $this->level;
}
}
/**
* Niveau d'un bâtiment de type ITelBatiment
*/
interface ITelBatimentStructureLevel extends IStructureLevel
{
}
/**
* Niveau d'un TelBatiment.
*/
class TelBatimentStructureLevel extends ABatimentStructureLevel implements ITelBatimentStructureLevel
{
protected $level = 5;
}
$niveauBatiment = new TelBatimentStructureLevel();
$calculateur = new TelBatimentSableCalculator();
$sableQuantite = $calculateur->calculate($niveauBatiment);
var_dump($sableQuantite);
}
?>En version "j'me contente des classes concrètes et zut pour les dépendances, interfaces, extensibilité et combinatoire", on peut ne garder que les classes concrètes "TelBatimentSableCalculator " et "TelBatimentStructureLevel".
Après, la quantité retournée devrait être typée (schématiquement sans tenir compte des dépendances engendrées et en mono-ligne, return new RessourceSableQuantite( pow($this->baseExponent, $p_structureLevel->getLevel() - 1) ); la classe représentant alors une quantité de la ressource "sable").
Si t'as plusieurs fois le même patron de fonction (exemple: n^p +q*p) alors tu peux en faire une autre classe ou une fonction (pourquoi pas pour le coup, c'est logique) et la réutiliser dans TelBatimentSableCalculator.