Il y a quelques années, lorsque je passais un entretien dans une grosse banque pour intégrer dans une équipe de coachs crafts, deux coachs m'avaient demandé comment j'assurais ma veille technologique. J'avais alors énuméré tout un tas de sites web dont développez.com et là... Je les ai vu grincer des dents mais genre fort fort fort...
Aujourd'hui, je vois un article qui s'intitule : Tutoriel pour apprendre à développer des objets Java et pas simplement des classes de données et dès le second écran je peux lire ceci :
public final class Assert {
private Assert() {}
public static void notNull(String fieldName, Object input) {
if (input == null) {
throw MissingMandatoryValueException.forNullValue(fieldName);
}
}
public static void notBlank(String fieldName, String input) {
if (input == null) {
throw MissingMandatoryValueException.forNullValue(fieldName);
}
if (input.isBlank()) {
throw MissingMandatoryValueException.forBlankValue(fieldName);
}
}
public static StringAsserter field(String fieldName, String value) {
return new StringAsserter(fieldName, value);
}
public static class StringAsserter {
private final String fieldName;
private final String value;
private StringAsserter(String fieldName, String value) {
this.fieldName = fieldName;
this.value = value;
}
public StringAsserter notBlank() {
Assert.notBlank(fieldName, value);
return this;
}
public StringAsserter maxLength(int maxLength) {
if (value != null && value.length() > maxLength) {
throw StringSizeExceededException
.builder()
.field(fieldName)
.currentLength(value.length())
.maxLength(maxLength).build();
}
return this;
}
}
}
Que des méthodes statiques, un constructeur privé pour bien empêcher les instances, aucun état représenté... Donc sans critiquer l'auteur et son envie de bien faire (car il a le mérite d'avoir écrit quelque chose), cet article rappelle effectivement des principes de l'OOP mais sans jamais les comprendre ni même en illustrer ne serait-ce qu'un seul exemple valable.
L'objet est aux antipodes du static
, si vous avez du code statique c'est foncièrement que vous ne codez pas en objet. Et là, le seul exemple de l'article est basé sur ça... Bref, article à mettre à la corbeille, navrée pour son auteur.
Je reprends l'exemple que j'avais donné ici et que j'ai modifié pour le "Yegorifier".
#![allow(non_snake_case)]
// Interface / Trait
trait Addition {
fn add(&self) -> i32;
}
// Couple
struct Couple {
opA: i32,
opB: i32,
}
impl Couple {
// Équivalent à une méthode 'static' de Java simulant un constructeur
fn new(opA: i32, opB: i32) -> Self {
return Couple { opA: opA, opB: opB }
}
}
// Triplet
struct Triplet {
opA: Box<dyn Addition>, // Un trait doit être passé dans un objet de type Box
opB: i32,
}
impl Triplet {
// Équivalent à une méthode 'static' de Java simulant un constructeur
fn new(opA: Box<dyn Addition>, opB: i32) -> Self {
return Triplet { opA: opA, opB: opB }
}
}
// Implémentations du trait "Addition"
impl Addition for Couple {
fn add(&self) -> i32 {
return self.opA + self.opB;
}
}
impl Addition for Triplet {
fn add(&self) -> i32 {
return (*self.opA).add() + self.opB;
}
}
// Exécution
fn main() {
let additionA = Couple::new(1, 2);
println!("Couple add : [{}]", additionA.add()); // Print 3
// Ne pas oublier de wrapper Couple dans une Box
let additionB = Triplet::new(Box::new(additionA), 3);
println!("Triplet add : [{}]", additionB.add()); // Print 6
}
Un bel exemple de refactoring de code static à base de factory methods.
Martin Fowler toujours aussi efficace dans ses explications.