Sortir les case du switch aurait l'intérêt de permettre la réutilisation de ces cases (un autre FileAggregator pourrait avoir les mêmes conditions sur des PDF, et remplacer les DXF/DWG par des 3DS; un autre aggregator aurait des DXF/DWG/3DS et c'est tout, etc).
Justement, le cas 3 (Un policier me demande mes papiers, en West, je dois les retourner, en East, je peux juste me barrer) est réalisable aussi en West (puisque null est implicitement retourné par PHP; le policier ne récupèrera... rien).
A la limite, on aurait plus de liberté si, au lieu de retourner les papiers, on retournait un pot de vin, mais en East, ce n'est pas non plus possible (puisque le "retour" est un appel à une méthode aval, qui doit respecter la signature de l'interface à laquelle elle est associée).
West
East:
Ou alors, c'est possible sur des langages "lâches" niveau typage (genre PHP), et West (class suiteProcess { function doSomething() { return $returned; }) ou East ($suiteProcess->doSomething($returned)) ont tous deux cette possibilité.
En West, FileAggregator n'a pas à s'inquiéter de FileUploader: quand une classe retourne une donnée, elle se moque de qui s'en sert, c'est donc une dépendance de moins?!
Justement, le cas 3 (Un policier me demande mes papiers, en West, je dois les retourner, en East, je peux juste me barrer) est réalisable aussi en West (puisque null est implicitement retourné par PHP; le policier ne récupèrera... rien).
A la limite, on aurait plus de liberté si, au lieu de retourner les papiers, on retournait un pot de vin, mais en East, ce n'est pas non plus possible (puisque le "retour" est un appel à une méthode aval, qui doit respecter la signature de l'interface à laquelle elle est associée).
West
interface Gens {
public Papiers getPapiers();
}
class Policier {
public void papierSvp(Gens $gens) {
$papiers = $gens->getPapiers();
}
}
class TypeNormal implements Gens {
public Papiers getPapiers() {
return this->papiers;
}
}
class Delinquant implements Gens {
public Papiers getPapiers() {
return null;
}
}
East:
interface Gens {
public Papiers donneTesPapiersA(PapiersReceveur pr);
}
interface PapiersReceveur {
public void voiciMesPapiers(Gens gens, Papiers papiers);
}
class Policier implements PapiersReceveur {
public void papierSvp(Gens $gens) {
$gens->donneTesPapiersA(this);
}
public void voiciMesPapiers(Gens gens, Papiers papiers) {
// ...
}
}
class TypeNormal implements Gens {
public Papiers donneTesPapiersA(PapiersReceveur pr) {
$pr->voiciMesPapiers(this, papiers);
}
}
class Delinquant implements Gens {
public Papiers donneTesPapiersA(PapiersReceveur pr) {
// Ne pas appeler voiciMesPapiers
}
}
Ou alors, c'est possible sur des langages "lâches" niveau typage (genre PHP), et West (class suiteProcess { function doSomething() { return $returned; }) ou East ($suiteProcess->doSomething($returned)) ont tous deux cette possibilité.
Citation :FileAggregator n'est pas dépendant de FileUploader, il sait travailler avec c'est différent.Je percute pas ça. En C++ (sûr), en PHP et en Java (quasi sûr), la classe FileUploader doit être importée par le FileAggregator. FileAggregator ne sait travailler avec FileUploader que parce que FileUploader respecte une signature de méthode, qui inclus ce que le FileAggregator retournais en West.
FileAggregator n'a pas besoin de FileUploader pour travailler.
En West, FileAggregator n'a pas à s'inquiéter de FileUploader: quand une classe retourne une donnée, elle se moque de qui s'en sert, c'est donc une dépendance de moins?!
