Une implémentation typique d'un référentiel DDD n'a pas l'air très OO, par exemple une save()méthode:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Partie infrastructure:
package com.example.infrastructure;
// imports...
public class JdbcProductRepo implements ProductRepo {
private JdbcTemplate = ...
public void save(Product product) {
JdbcTemplate.update("INSERT INTO product (name, price) VALUES (?, ?)",
product.name, product.price);
}
}
Une telle interface s'attend Productà ce que a soit un modèle anémique, au moins avec des getters.
D'un autre côté, la POO dit qu'un Productobjet doit savoir comment se sauver.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
Le fait est que lorsque le Productsait se sauver, cela signifie que le code d'infrastructure n'est pas séparé du code de domaine.
Peut-être pouvons-nous déléguer l'enregistrement à un autre objet:
package com.example.domain;
public class Product {
private String name;
private Double price;
void save(Storage storage) {
storage
.with("name", this.name)
.with("price", this.price)
.save();
}
}
public interface Storage {
Storage with(String name, Object value);
void save();
}
Partie infrastructure:
package com.example.infrastructure;
// imports...
public class JdbcProductRepo implements ProductRepo {
public void save(Product product) {
product.save(new JdbcStorage());
}
}
class JdbcStorage implements Storage {
private final JdbcTemplate = ...
private final Map<String, Object> attrs = new HashMap<>();
private final String tableName;
public JdbcStorage(String tableName) {
this.tableName = tableName;
}
public Storage with(String name, Object value) {
attrs.put(name, value);
}
public void save() {
JdbcTemplate.update("INSERT INTO " + tableName + " (name, price) VALUES (?, ?)",
attrs.get("name"), attrs.get("price"));
}
}
Quelle est la meilleure approche pour y parvenir? Est-il possible d'implémenter un référentiel orienté objet?
6
OOP dit qu'un objet produit devrait savoir comment se sauver - je ne suis pas sûr que ce soit vraiment correct ... OOP en soi ne le dicte pas vraiment, c'est plus un problème de conception / modèle (c'est là que DDD / n'importe quoi -use arrive)
—
jleach
N'oubliez pas que dans le contexte de la POO, il s'agit d'objets. Juste des objets, pas la persistance des données. Votre déclaration indique que l'état d'un objet ne doit pas être géré en dehors de lui, ce avec quoi je suis d'accord. Un référentiel est chargé de charger / enregistrer à partir d'une couche de persistance (qui est en dehors du domaine de la POO). Les propriétés et méthodes de classe doivent conserver leur propre intégrité, oui, mais cela ne signifie pas qu'un autre objet ne peut pas être responsable de la persistance de l'état. Et, les getters et setters doivent assurer l'intégrité des données entrantes / sortantes de l'objet.
—
jleach
"cela ne signifie pas qu'un autre objet ne peut pas être responsable de la persistance de l'Etat." - Je n'ai pas dit ça. L'énoncé important est qu'un objet doit être actif . Cela signifie que l'objet (et personne d'autre) ne peut déléguer cette opération à un autre objet, mais pas l'inverse: aucun objet ne doit simplement collecter des informations à partir d'un objet passif pour traiter sa propre opération égoïste (comme le ferait un dépôt avec les getters) . J'ai essayé d'implémenter cette approche dans les extraits ci-dessus.
—
ttulka
@jleach Vous avez raison, notre compréhension de la POO est différente, pour moi les getters + setters ne sont pas du tout POO, sinon ma question n'avait aucun sens. Merci quand même! :-)
—
ttulka
Voici un article sur mon point: martinfowler.com/bliki/AnemicDomainModel.html Je ne suis pas contre le modèle anémique dans tous les cas, par exemple c'est une bonne stratégie pour la programmation fonctionnelle. Mais pas OOP.
—
ttulka