2012-01-10 21 views
9

Hiện tại đang thực hiện một số đánh giá mã về nội dung được chuyển từ một nhóm khác và có một nghi ngờ về việc áp dụng SRP và mối quan hệ của nó với mô hình miền thiếu hoặc giàu (theo định nghĩa của Martin Fowler). Khái niệm mô hình miền phong phú là có đối tượng thông minh không chỉ có thể thiết lập/nhận các thuộc tính của chúng mà còn có thể thực hiện một số logic kinh doanh phức tạp hơn. Tôi tự hỏi làm thế nào nó phù hợp với SRP?Nguyên tắc về trách nhiệm một đơn liên quan đến mô hình miền thiếu/giàu có như thế nào?

Giả sử tôi có lớp mô hình của mình có một số thuộc tính có thể hiển thị các đạo cụ đó và cung cấp một số tính toán đơn giản về tính thích hợp của nó. Yêu cầu tiếp theo là phải có khả năng lưu trữ đối tượng dữ liệu này trong một số đối tượng lưu trữ mà không phải là dưới sự kiểm soát của tôi, như thế này: Phương pháp

class MyObject { 
    // get set 
    // parse sth 

} 

Store trong lưu trữ

storage.store(key, object); 

Không nó vi phạm SRP nếu MyObject có phương pháp lưu trữ như thế này

public void store(Storage storage) { 
    storage.store('keyOne', fieldOne); 
    storage.store('keyTwo', fieldTwo); 
} 

Từ pov của đối tượng này, bạn nên lưu trữ trạng thái của nó. cách khác có thể là để giới thiệu loại dịch vụ ở đây và làm điều này như thế:

public StorageService { 
    private Storage; 
    // constructor here 
    .... 
    public void store(MyObject myobj); 
} 

Bạn có thể chỉ cho tôi bất kỳ liên kết Tôi có thể đọc về vấn đề này? Tôi đã tìm thấy một thread trên SO ở đây nhưng nó không trả lời câu hỏi của tôi hoàn toàn.

Cách giải quyết trong DDD? Các mô hình trong DDD theo định nghĩa phong phú và có thể được xem là có quá nhiều trách nhiệm.

+3

Đó có thể là giải thích quá mức về SRP. Bỏ qua chú Bob và đi tìm "sự gắn kết". –

+0

Như đã lưu ý trong câu trả lời của tôi, nếu Bộ lưu trữ ổn định và trừu tượng (ví dụ, một số giao diện JSON, XML, RDB chuẩn) thì IMO, hoàn toàn không có vấn đề gì cho sự gắn kết và đưa nó vào mô hình miền. – user949300

Trả lời

6

Một mô hình miền giàu (RDM) có nghĩa là Logic quản lý của mô hình hành vi thuộc trong mô hình, như trái ngược với điều trị các mô hình như dữ liệu với getters/setters. Điều này làm không có nghĩa là tất cả mọi thứ bao gồm cả sự kiên trì, bảo mật, cách hiển thị mô hình trong GUI, v.v. cần phải nằm trong mô hình.

RDM và SRP đi đôi với nhau, chúng không xung đột với nhau.

Vi phạm SRP/RDM:

Car { 
    // possibly violates SRP 
    storeInDatabase(); 
    // smells like anemic domain model 
    getEngineState(); 
} 

Sau SRP/RDM:

// usings aspects to remove cross-cutting concerns from the model and follow SRP 
@DatabaseSerializable 
Car { 
    // rich domain model encapsulates engine state and exposes behavior 
    drive();    
} 
+1

Nếu bạn có một chiếc xe với nhiều phương pháp khác ngoài Drive(), ví dụ SwitchOn(), SwitchOff(), Turn(), Brake(), PlanRoute(), bạn có RDM, nhưng bạn không có SRP. Lớp học của bạn càng phong phú với hành vi, nó càng đi ngược lại với SRP. Đây là những ý tưởng phản đối. –

+0

RDM có nghĩa là mô hình của bạn nên chứa logic miền. SRP có nghĩa là các lớp của bạn phải chịu trách nhiệm cho một điều - trong trường hợp của mô hình nó có nghĩa là 'chứa logic miền' và không chứa mã tuần tự hoặc mã mở kết nối web, v.v. –

+0

Tôi biết ý nghĩa. JuanZe nói điều tốt nhất: "Các mô hình trong DDD theo định nghĩa phong phú và có thể được xem là có quá nhiều trách nhiệm". Nói cách khác, không dễ dàng để thực hiện một thực thể giàu có thực sự mà không có thực thể đó có quá nhiều trách nhiệm (nhiều hơn 1). Trừ khi tất nhiên chúng tôi tiêm các dịch vụ/đối tượng chịu trách nhiệm duy nhất vào nó, trong trường hợp đó là ADM đường biên. –

4

"Mô hình trong DDD có định nghĩa phong phú và có thể được xem là có quá nhiều trách nhiệm" là cách hiểu đơn giản về DDD. Luôn luôn nó phụ thuộc vào cách tốt là mô hình của bạn. Bạn có thể tạo ra các mô hình xấu bằng cách sử dụng DDD (ví dụ như tạo các đối tượng có quá nhiều sự phản hồi hoặc tạo các mô hình thiếu máu). DDD và SRP là hai cách thực hành tốt, theo như tái cấu trúc, TDD và nhiều hơn nữa, nhưng bạn nên bổ sung cho việc sử dụng chúng với kinh nghiệm và sự phán xét của bạn (hoặc của người khác). Mọi thứ đều có những ưu và khuyết điểm của nó, không phải là giáo điều về việc áp dụng bất kỳ thực hành nào.

3

@Garrett sảnh

Tôi hơi không đồng ý với tuyên bố của bạn "RDM và SRP đi trong tay, họ không mâu thuẫn với nhau."Theo kinh nghiệm của tôi, khi SRP bị quá tải, nó dẫn đến một mô hình miền thiếu máu." Không, chúng tôi không thể làm hoặc thậm chí giúp hỗ trợ bất kỳ sự kiên trì nào, không, chúng tôi không thể làm 21 CFR11, không, chúng tôi không thể thậm chí biết GUI là gì ... "và lớp học của bạn kết thúc bằng cách thực hiện không có gì là và chỉ có Mô hình miền thiếu dịch.

Và nếu RDM bị quá tải (đó là hướng/lỗi tôi có xu hướng rơi vào) thì SRP hoàn toàn rơi vào bên lề đường và cuối cùng bạn nhận thấy rằng lớp học của bạn có 100 phương pháp và rõ ràng đang làm quá nhiều

Bạn cần tìm sự cân bằng, phương tiện hạnh phúc nơi cả RDM và SRP đang diễn ra. khó khăn và thường liên quan đến nhiều cảm xúc và chính trị trong đội của bạn hơn là hiểu biết về kỹ thuật hoặc quy tắc.

"Biết bản thân mình". Nếu bạn giống tôi, và có xu hướng hướng tới các lớp quá phức tạp, hãy lưu ý. Và khi bạn thấy lớp của người khác trông quá phức tạp ngay cả với bạn, đó là một lá cờ đỏ lớn. Tương tự như vậy, nếu bạn biết rằng bạn khá hardcore về SRP, và bạn thấy một lớp học trông thiếu máu ngay cả theo tiêu chuẩn của bạn, đó là một mùi mã chính.

Bây giờ, phần nào trả lời câu hỏi của OP về Bộ nhớ, tôi nghĩ rất nhiều tùy thuộc vào cách Bộ nhớ ổn định, chuẩn và trừu tượng. Nếu lưu trữ là một số tiêu chuẩn XML, CSV, hoặc RDB trừu tượng, tôi hoàn toàn không có vấn đề với các đối tượng biết làm thế nào để lưu trữ bản thân.

+0

SRP nói rằng một lớp học sẽ có một lý do để thay đổi, và nó có nghĩa là một nguồn lý do để thay đổi. Vì vậy, khi các hành vi khác nhau tồn tại cho một đối tượng, chúng sẽ được phân tách thành các lớp khác nhau và các lớp đó (là các dịch vụ trong DDD) thuộc về mô hình miền. –

Các vấn đề liên quan