Sự khác biệt giữa Nguyên tắc Trách nhiệm Đơn lẻ và Phân tách Mối quan tâm là gì?
Câu trả lời:
Nguyên tắc Trách nhiệm Đơn lẻ (SRP) - chỉ cho mỗi lớp một lý do để thay đổi; và “Lý do thay đổi” == “trách nhiệm”. Ví dụ: Lớp hóa đơn không có trách nhiệm tự in.
Tách Mối Quan Tâm (từ năm 1974). Mối quan tâm == tính năng của hệ thống. Quan tâm đến từng mối quan tâm: đối với mỗi mối quan tâm này, các mối quan tâm khác là không liên quan. Trốn thực hiện hành vi.
Từ đây .
Theo tôi, Nguyên tắc Trách nhiệm Đơn lẻ là một trong những công cụ / thành ngữ để đạt được Tách các Mối quan tâm.
Tách Mối quan tâm và Nguyên tắc Trách nhiệm Đơn lẻ (SoC so với SRP)
Từ bài viết được liên kết:
Tách các Mối quan tâm (SoC) - là quá trình chia nhỏ một chương trình máy tính thành các tính năng riêng biệt trùng lặp về chức năng càng ít càng tốt. Mối quan tâm là bất kỳ phần nào quan tâm hoặc trọng tâm trong một chương trình. Thông thường, mối quan tâm đồng nghĩa với các tính năng hoặc hành vi. http://en.wikipedia.org/wiki/Sepilities_of_concerns
Nguyên tắc trách nhiệm duy nhất (SRP) - mọi đối tượng phải có một trách nhiệm duy nhất và tất cả các dịch vụ của nó phải phù hợp với trách nhiệm đó. Ở một mức độ nào đó, Cohesion được coi là từ đồng nghĩa với SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
Trách nhiệm đơn lẻ nói rằng một Đối tượng chịu trách nhiệm cho một đơn vị công việc.
Phân tách mối quan tâm nói rằng các ứng dụng nên được chia thành các mô-đun có chức năng trùng lặp càng ít càng tốt.
Kết quả cuối cùng tương tự ... các ứng dụng hơi khác nhau.
Nguyên tắc Trách nhiệm Đơn lẻ và Tách các Mối quan tâm thực sự giống nhau.
Chắc chắn bạn có thể bị sa lầy vào một cuộc thảo luận học thuật khi cố gắng tìm ra sự khác biệt nào đó giữa hai người, nhưng tại sao? Đối với tất cả các ý định và mục đích họ mô tả cùng một điều. Vấn đề lớn nhất là mọi người bị cuốn vào việc muốn biết chính xác "mối quan tâm" và "trách nhiệm" là gì, đến nỗi họ có thể bỏ lỡ ý tưởng quan trọng đằng sau SRP và SoC.
Ý tưởng đó chỉ đơn giản là chia cơ sở mã của bạn thành các phần biệt lập được ghép nối lỏng lẻo. Điều này cho phép nhiều nhà phát triển làm việc trên các phần khác nhau mà không ảnh hưởng đến nhau, nó cũng cho phép một nhà phát triển duy nhất sửa đổi một phần riêng biệt mà không phá vỡ phần khác.
Điều này được áp dụng ở cấp độ mô-đun, ví dụ MVC là một mẫu kiến trúc thúc đẩy SRP và SoC. Cơ sở mã được chia thành các mô hình, chế độ xem và bộ điều khiển riêng biệt. Bằng cách đó, việc sửa đổi một khung nhìn có thể được thực hiện độc lập với một mô hình. Hai hai không đan xen nhau một cách kinh khủng.
Ở cấp độ thấp hơn, điều này cũng nên được áp dụng cho các lớp. Thay vì đặt hàng chục phương thức trong một lớp, hãy chia mã thành nhiều phương thức. Vì những lý do tương tự.
Ngoài ra, ngay cả ở cấp phương pháp, hãy chia nhỏ các phương thức lớn thành các phương thức nhỏ hơn.
Về nguyên tắc. SRP là một nguyên tắc, không phải là một quy tắc, vì vậy bạn không cần phải (đọc: không thể / không nên) tuân theo nó một cách tôn giáo đến cùng cực. Nó không có nghĩa là đi quá xa và chỉ có một phương thức bảy dòng trong mỗi lớp chẳng hạn. Nó chỉ có nghĩa là một nguyên tắc chung của việc tách mã thành các phần riêng biệt. Vấn đề là nó sẽ dẫn đến một cơ sở mã tốt hơn và phần mềm ổn định hơn.
Phân tách các mối quan tâm (SoC). Chia ứng dụng của bạn thành các tính năng riêng biệt với càng ít trùng lặp về chức năng càng tốt. (Microsoft).
“Mối quan tâm” = “tính năng khác biệt” = “phần riêng biệt”
"Sự quan tâm" hoạt động ở cả cấp độ cao và cấp thấp
Nguyên tắc trách nhiệm duy nhất nói rằng mọi mô-đun hoặc lớp phải có trách nhiệm đối với một phần chức năng được cung cấp bởi phần mềm và trách nhiệm đó phải được gói gọn hoàn toàn bởi lớp. Tất cả các dịch vụ của nó phải phù hợp với trách nhiệm đó. (Wikipedia định nghĩa)
“Trách nhiệm” = “lý do để thay đổi” thay đổi điều gì? “Một phần của chức năng do phần mềm cung cấp” = Đơn vị cơ bản
Phần kết luận
Nguyên tắc trách nhiệm duy nhất hoạt động trên các đơn vị cơ bản -> hoạt động ở mức thấp
Phân tách các mối quan tâm hoạt động ở cả cấp độ cao và thấp
SRP và SoC làm việc cùng nhau để tách các mối quan tâm. Chúng
hoàn toàn giống nhau ở cấp độ thấp
Vì không có câu trả lời nào trước đây trích dẫn Robert Martin, người đã tạo ra Nguyên tắc trách nhiệm duy nhất , tôi nghĩ rằng cần có một câu trả lời có thẩm quyền hơn ở đây.
Nguồn cảm hứng của Martin cho SRP được lấy từ David Parnas, Edsger Dijkstra (người đặt ra thuật ngữ Phân tách mối quan tâm ) và Larry Constantine (người đặt ra thuật ngữ Khớp nối và Liên kết ). Martin đã hợp nhất các ý tưởng của họ vào SRP.
Một cách diễn đạt khác cho Nguyên tắc Trách nhiệm Đơn lẻ là:
Tập hợp những điều thay đổi vì những lý do giống nhau. Tách những thứ thay đổi vì những lý do khác nhau.
Nếu bạn nghĩ về điều này, bạn sẽ nhận ra rằng đây chỉ là một cách khác để xác định sự gắn kết và khớp nối. Chúng tôi muốn tăng sự gắn kết giữa những thứ thay đổi vì những lý do giống nhau và chúng tôi muốn giảm sự gắn kết giữa những thứ thay đổi vì những lý do khác nhau.
Tuy nhiên, khi bạn nghĩ về nguyên tắc này, hãy nhớ rằng lý do thay đổi là do con người . Đó là những người yêu cầu thay đổi. Và bạn không muốn nhầm lẫn những người đó hoặc chính mình bằng cách trộn lẫn mã mà nhiều người khác nhau quan tâm vì những lý do khác nhau.
Đối với câu hỏi ban đầu, sự khác biệt nhỏ giữa SRP và SoC là Martin đã tinh chỉnh thuật ngữ mối quan tâm để chỉ con người .
Phân tách các mối quan tâm là một quá trình; Nguyên tắc Trách nhiệm Đơn lẻ là một triết lý thiết kế / kiến trúc. Chúng không hoàn toàn rời rạc, nhưng chúng phục vụ các mục đích khác nhau.
SRP và SOC hoạt động ở các mức độ trừu tượng khác nhau. Mục đích trong cả hai trường hợp là để giảm sự ghép nối và tăng cường sự gắn kết. Trong khi SRP hoạt động nhiều hơn ở cấp độ đối tượng, SOC cũng có thể hoạt động trên việc triển khai cấp chức năng. Một chức năng có thể được thực hiện bởi một đối tượng nhưng cũng có thể được thực hiện bởi một số đối tượng. Do đó sự khớp nối và sự gắn kết của cả hai nguyên tắc có thể khác nhau.
Tôi đã cố gắng rút ra một so sánh giữa Phân tách các mối quan tâm (SoC) và Nguyên tắc Trách nhiệm Đơn lẻ (SRP).
Sự khác biệt
SRP ở cấp độ lớp, nhưng SoC nằm trong mỗi chương trình máy tính, sự trừu tượng ... hoặc đôi khi là cấp độ kiến trúc.
SRP là về chất lượng của việc phân chia miền của bạn thành các lớp gắn kết chỉ có một trách nhiệm (một lý do để thay đổi). Mặt khác, SoC là một nguyên tắc thiết kế để tách ngữ cảnh thành các phần riêng biệt, sao cho mỗi phần giải quyết một mối quan tâm riêng (chứ không phải như thế nào), vì có rất nhiều công cụ (ví dụ như lớp, hàm, mô-đun, gói,. ..) để đạt được mục tiêu này ở các mức độ khác nhau.
Khái niệm SRP dựa trên sự gắn kết (tính liên kết cao), ngược lại SoC gần với Molecularity, chia và chinh phục (D&C), ... theo từng cấp độ trừu tượng.
SoC là một nguyên tắc thiết kế tốt để đối phó với sự phức tạp, chẳng hạn như trừu tượng trong khi để đạt được các lớp chịu trách nhiệm đơn lẻ, bạn có thể sử dụng nguyên tắc SoC như một giải pháp tuyệt vời. Như, một cách để biết rằng một lớp có nhiều hơn một trách nhiệm là nếu bạn có thể trích xuất một trách nhiệm (mối quan tâm) khác từ lớp đó.
Điểm tương đồng
Câu trả lời:
Phân tách mối quan tâm (SoC) là một thuật ngữ linh hoạt hơn - nó có thể được áp dụng ở cấp hệ thống hoặc ở cấp thấp hơn như các lớp (hoặc thậm chí các phương thức trong một lớp)
Nguyên tắc Trách nhiệm Đơn lẻ (SRP) được sử dụng để thảo luận về SoC ở các cấp thấp hơn, ví dụ như trong một lớp
Cách nghĩ về nó:
Ở cấp độ thấp, SoC và SRP đồng nghĩa với nhau. Vì vậy, bạn có thể nói SRP là một thuật ngữ thừa - hoặc rằng SoC chỉ nên được sử dụng để thảo luận về mức hệ thống
Với (1), thuật ngữ SoC hơi mơ hồ. Bạn cần bối cảnh để biết cuộc thảo luận là về SoC cấp cao hay SoC cấp thấp hơn
Để nhớ rằng SRP là thuật ngữ chỉ các cấp thấp hơn, hãy nghĩ về điều này: trong ngôn ngữ hàng ngày, "trách nhiệm" thường là một thứ được xác định rõ ràng có thể được gắn với mã cụ thể, trong khi "mối quan tâm" thường mơ hồ và có thể bao gồm một loạt những thứ liên quan, đó có lẽ là lý do tại sao SoC phù hợp tự nhiên hơn để thảo luận về cấp hệ thống hơn là SRP
SoC là trong một số cảm giác một mạnh yêu cầu / nguyên tắc hơn SRP vì nó áp dụng ở cấp hệ thống, và để được thực sự đạt được ở cấp hệ thống cũng phải được sử dụng trong việc phát triển các thành phần hệ thống. Có nghĩa là, mức SoC cao có nghĩa là SoC / SRP tốt ở các mức thấp hơn - nhưng điều ngược lại là không đúng, nghĩa là SoC / SRP ở mức thấp hơn không ngụ ý SoC hoặc bất kỳ thứ gì cho mức cao hơn tiếp theo, đừng bận tâm đến hệ thống bao gồm. Để biết ví dụ về SoC / SRP đạt được ở cấp phương pháp, nhưng sau đó bị vi phạm ở cấp lớp, hãy xem bài đăng trên blog này của Artur Trosin .
Tách các mối quan tâm
Nguyên tắc Tách mối quan tâm (SOC) nói rằng một tạo tác mã nên cho phép người ta tập trung sự chú ý của mình vào một khía cạnh nhất định. Tạo tác mã có thể là bất kỳ thứ gì, từ một hàm cụ thể, đến một lớp, hoặc toàn bộ gói, hoặc thậm chí toàn bộ ứng dụng. Nguyên tắc SOC có thể được áp dụng cho mọi cấp độ kiến trúc trong các ứng dụng của một người. Một ví dụ về kiến trúc mà SOC được áp dụng là kiến trúc phân lớp.
Nguyên tắc trách nhiệm đơn lẻ
Nguyên tắc Trách nhiệm Duy nhất (SRP) nói rằng "Một mô-đun nên có một, và chỉ một, lý do để thay đổi" (Clean Architecture, Martin, p. 62). SRP áp dụng cho cấp độ mô-đun và khi áp dụng SRP cần tập trung vào lý do thay đổi.
Phần kết luận
Nguyên tắc SOC tuyên bố rằng một tạo tác mã phải cho phép người ta tập trung sự chú ý của mình vào một khía cạnh nhất định. SRP làm cho điều này cụ thể bằng cách nêu rõ rằng ở cấp độ mô-đun, chúng ta nên tập trung sự chú ý của mình vào lý do thay đổi. Do đó SRP là một SOC.
Tái bút cho sự hoàn chỉnh: Nguyên tắc Đóng cửa Chung
Nguyên tắc Đóng cửa Chung (CCP) là một bản trình bày lại SRP ở cấp độ thậm chí cao hơn, cấp độ thành phần. ĐCSTQ tuyên bố rằng các lớp thay đổi vì những lý do giống nhau và đồng thời nên được tập hợp thành các thành phần giống nhau (Kiến trúc sạch, trang 105). CCP là một ví dụ khác về SOC.