Flup đang đi đúng hướng. "Nguyên tắc trách nhiệm duy nhất" ban đầu được áp dụng cho các thủ tục. Ví dụ, Dennis Ritchie sẽ nói rằng một hàm nên làm một việc và làm tốt. Sau đó, trong C ++, Bjarne Stroustrup sẽ nói rằng một lớp nên làm một việc và làm tốt.
Lưu ý rằng, ngoại trừ quy tắc ngón tay cái, hai chính thức này có rất ít hoặc không có gì để làm với nhau. Chúng chỉ phục vụ cho những gì thuận tiện để diễn đạt bằng ngôn ngữ lập trình. Vâng, đó là một cái gì đó. Nhưng đó là một câu chuyện hoàn toàn khác so với những gì flup đang lái xe.
Các triển khai hiện đại (tức là nhanh nhẹn và DDD) tập trung nhiều vào những gì quan trọng đối với doanh nghiệp hơn là những gì ngôn ngữ lập trình có thể diễn đạt. Phần đáng ngạc nhiên là các ngôn ngữ lập trình chưa bắt kịp. Các ngôn ngữ cũ giống như FORTRAN nắm bắt các trách nhiệm phù hợp với các mô hình khái niệm chính của thời đại: các quy trình được áp dụng cho mỗi thẻ khi nó đi qua đầu đọc thẻ, hoặc (như trong C) xử lý đi kèm với mỗi ngắt. Sau đó, đến các ngôn ngữ ADT, đã trưởng thành đến mức nắm bắt được những gì mà người DDD sau này sẽ phát minh lại là quan trọng (mặc dù Jim Neighbor đã tìm ra hầu hết những điều này, được xuất bản và sử dụng vào năm 1968): ngày nay chúng ta gọi là các lớp học . (Chúng KHÔNG phải mô-đun.)
Bước này là một sự tiến hóa ít hơn một quả lắc. Khi con lắc vung lên dữ liệu, chúng tôi đã mất mô hình ca sử dụng vốn có trong FORTRAN. Điều đó tốt khi trọng tâm chính của bạn liên quan đến dữ liệu hoặc hình dạng trên màn hình. Đây là một mô hình tuyệt vời cho các chương trình như PowerPoint hoặc ít nhất là cho các hoạt động đơn giản của nó.
Những gì đã mất là trách nhiệm hệ thống . Chúng tôi không bán các yếu tố của DDD. Và chúng tôi không phương pháp lớp tốt. Chúng tôi bán trách nhiệm hệ thống. Ở một mức độ nào đó, bạn cần thiết kế hệ thống của mình theo nguyên tắc trách nhiệm duy nhất.
Vì vậy, nếu bạn nhìn vào những người như Rebecca Wirfs-Brock, hoặc tôi, người thường nói về các phương pháp của lớp, thì bây giờ chúng ta đang nói về các trường hợp sử dụng. Đó là những gì chúng tôi bán. Đó là những hoạt động hệ thống. Một trường hợp sử dụng nên có một trách nhiệm duy nhất. Một trường hợp sử dụng hiếm khi là một đơn vị kiến trúc. Nhưng mọi người đều cố gắng giả vờ như vậy. Chứng kiến những người làm ví dụ.
Đây là lý do tại sao tôi rất hào hứng với kiến trúc DCI của Trygve Reenskaug - đó là những gì được mô tả trong cuốn sách Kiến trúc Lean ở trên. Cuối cùng nó đưa ra một số tầm vóc thực sự cho những gì từng là sự phản đối tùy tiện và thần bí đối với "trách nhiệm duy nhất" - như người ta thấy trong hầu hết các cuộc tranh luận ở trên. Tầm vóc đó liên quan đến các mô hình tinh thần của con người: người dùng cuối trước và lập trình viên thứ hai. Nó liên quan đến mối quan tâm kinh doanh. Và, gần như tình cờ, nó gói gọn sự thay đổi khi flup thách thức chúng ta.
Nguyên tắc trách nhiệm duy nhất mà chúng ta biết đó là một con khủng long còn sót lại từ thời kỳ khởi đầu hoặc một con ngựa có sở thích mà chúng ta sử dụng thay thế cho sự hiểu biết. Bạn cần phải bỏ lại một vài con ngựa có sở thích này để làm phần mềm tuyệt vời. Và điều đó đòi hỏi phải suy nghĩ ra khỏi hộp. Giữ mọi thứ đơn giản và dễ hiểu chỉ hoạt động khi vấn đề đơn giản và dễ hiểu. Tôi không quan tâm lắm đến những giải pháp đó: chúng không phải là điển hình và đó không phải là thách thức.
