Uma implementação típica de um repositório DDD não parece muito OO, por exemplo, um save()método:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Parte da infraestrutura:
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);
}
}
Essa interface espera Productque seja um modelo anêmico, pelo menos com getters.
Por outro lado, o OOP diz que um Productobjeto deve saber como se salvar.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
O problema é que, quando ele Productsabe como se salvar, significa que o código da infraestrutura não é separado do código do domínio.
Talvez possamos delegar a gravação em outro objeto:
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();
}
Parte da infraestrutura:
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"));
}
}
Qual é a melhor abordagem para conseguir isso? É possível implementar um repositório orientado a objetos?
6
OOP diz que um objeto Product deve saber como se salvar - não tenho certeza se isso está realmente correto ... OOP em si não dita isso, é mais um problema de design / padrão (que é onde DDD / o que você quiser) -Use vem em)
—
jleach
Lembre-se de que, no contexto de POO, está falando sobre objetos. Apenas objetos, não persistência de dados. Sua declaração indica que o estado de um objeto não deve ser gerenciado fora de si, o que eu concordo. Um repositório é responsável por carregar / salvar de alguma camada de persistência (que está fora do domínio do OOP). As propriedades e métodos da classe devem manter sua própria integridade, sim, mas isso não significa que outro objeto não possa ser responsável pela persistência do estado. E, getters e setters devem garantir a integridade dos dados de entrada / saída do objeto.
—
jleach
"isso não significa que outro objeto não possa ser responsável pela persistência do estado." Eu não disse isso. A afirmação importante é que um objeto deve estar ativo . Isso significa que o objeto (e ninguém mais) pode delegar essa operação para outro objeto, mas não o contrário: nenhum objeto deve apenas coletar informações de um objeto passivo para processar sua própria operação egoísta (como um repositório faria com getters) . Tentei implementar essa abordagem nos trechos acima.
—
ttulka
@jleach Você está certo, nossa compreensão do OOP é diferente, para mim, getters + setters não são OOP, caso contrário, minha pergunta não fazia sentido. Obrigado mesmo assim! :-)
—
ttulka
Aqui está um artigo sobre o meu argumento: martinfowler.com/bliki/AnemicDomainModel.html Não conheço o modelo anêmico em todos os casos, por exemplo, é uma boa estratégia para a programação funcional. Apenas não OOP.
—
ttulka 9/02/19