Một triển khai điển hình của kho lưu trữ DDD trông không giống OO, ví dụ như một save()phương thức:
package com.example.domain;
public class Product { /* public attributes for brevity */
public String name;
public Double price;
}
public interface ProductRepo {
void save(Product product);
}
Phần cơ sở hạ tầng:
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);
}
}
Một giao diện như vậy hy vọng sẽ Productlà một mô hình thiếu máu, ít nhất là với getters.
Mặt khác, OOP nói rằng một Productđối tượng nên biết cách tự cứu mình.
package com.example.domain;
public class Product {
private String name;
private Double price;
void save() {
// save the product
// ???
}
}
Vấn đề là, khi Productbiết cách tự lưu, điều đó có nghĩa là mã cơ sở hạ tầng không tách rời khỏi mã miền.
Có lẽ chúng ta có thể ủy thác việc tiết kiệm cho một đối tượng khác:
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();
}
Phần cơ sở hạ tầng:
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"));
}
}
Cách tiếp cận tốt nhất để đạt được điều này là gì? Có thể thực hiện một kho lưu trữ hướng đối tượng?
6
OOP nói rằng một đối tượng Sản phẩm nên biết cách tự cứu mình - Tôi không chắc điều đó thực sự đúng ... Bản thân OOP không thực sự cho rằng đó là vấn đề về thiết kế / mẫu (đó là vấn đề DDD / sao cũng được
—
-Sử
Hãy nhớ rằng trong bối cảnh của OOP, nó đang nói về các đối tượng. Chỉ là đối tượng, không kiên trì dữ liệu. Tuyên bố của bạn chỉ ra rằng trạng thái của một đối tượng không nên được quản lý bên ngoài mà tôi đồng ý. Một kho lưu trữ chịu trách nhiệm tải / lưu từ một số lớp kiên trì (nằm ngoài lãnh địa của OOP). Các thuộc tính và phương thức lớp nên duy trì tính toàn vẹn của riêng chúng, vâng, nhưng điều này không có nghĩa là một đối tượng khác không thể chịu trách nhiệm cho việc duy trì trạng thái. Và, getters và setters là để đảm bảo tính toàn vẹn của dữ liệu đến / đi của đối tượng.
—
jleach
"điều này không có nghĩa là một đối tượng khác không thể chịu trách nhiệm cho việc duy trì nhà nước." - Tôi không nói thế. Tuyên bố quan trọng là, một đối tượng nên hoạt động . Nó có nghĩa là đối tượng (và không ai khác) có thể ủy thác thao tác này cho đối tượng khác, nhưng không phải là cách khác: không đối tượng nào chỉ nên thu thập thông tin từ một đối tượng thụ động để xử lý hoạt động ích kỷ của chính mình (như một repo sẽ làm với getters) . Tôi đã cố gắng thực hiện phương pháp này trong đoạn trích ở trên.
—
ttulka
@jleach Bạn nói đúng, việc hủy bỏ OOP của chúng tôi là khác nhau, đối với tôi getters + setters hoàn toàn không phải là OOP, nếu không thì câu hỏi của tôi không có ý nghĩa gì. Dù sao cũng cảm ơn bạn :-)
—
ttulka
Đây là một bài viết về quan điểm của tôi: martinfowler.com/bliki/AnemiaDomainModel.html Tôi không làm phiền mô hình thiếu máu trong mọi trường hợp, ví dụ đó là một chiến lược tốt cho lập trình chức năng. Chỉ là không OOP.
—
ttulka