a) Sự khác biệt giữa SRP và SoC là gì? Có lẽ SRP được áp dụng ở cấp độ lớp, trong khi SoC có thể được áp dụng ở cấp độ hệ thống , hệ thống con , mô-đun , lớp hoặc chức năng .
b) Nếu câu trả lời cho a) là có, thì SoC được áp dụng ở cấp lớp có phải là từ đồng nghĩa với SRP không?
cảm ơn bạn
Câu trả lời:
Nguyên tắc trách nhiệm duy nhất là về mã của bạn chỉ thực hiện 1 điều và bạn có thể phân chia tất cả các chức năng trong một số lớp, tất cả đều có nghĩa là để thực hiện 1 điều cụ thể. Một ví dụ là một lớp cụ thể để xác nhận, thực hiện một số logic nghiệp vụ, làm phong phú một mô hình, lấy dữ liệu, cập nhật dữ liệu, điều hướng, v.v.
Phân tách mối quan tâm là về mã của bạn không được liên kết chặt chẽ với một số lớp / hệ thống khác. Sử dụng các giao diện trong mã của bạn sẽ giúp ích rất nhiều, theo cách này bạn có thể kết nối một cách lỏng lẻo các lớp / hệ thống với mã của mình. Một điều khó khăn ở đây là việc kiểm tra mã của bạn cũng dễ dàng hơn. Có rất nhiều khung (IoC) có thể giúp bạn đạt được điều này, nhưng dĩ nhiên bạn cũng có thể thực hiện một điều như vậy.
Một ví dụ về một cái gì đó SoC, nhưng không có SRP
public class Foo
{
private readonly IValidator _validator;
private readonly IDataRetriever _dataRetriever;
public Foo(IValidator validator, IDataRetriever dataRetriever)
{
_validator = validator;
_dataRetriever = dataRetriever;
}
public NavigationObject GetDataAndNavigateSomewhereIfValid()
{
var data = _dataRetriever.GetAllData();
if(_validator.IsAllDataValid(data))
{
object b = null;
foreach (var item in data.Items)
{
b = DoSomeFancyCalculations(item);
}
if(_validator.IsBusinessDataValid(b))
{
return ValidBusinessLogic();
}
}
return InvalidItems();
}
private object DoSomeFancyCalculations(object item)
{
return new object();
}
private NavigationObject ValidBusinessLogic()
{
return new NavigationObject();
}
private NavigationObject InvalidItems()
{
return new NavigationObject();
}
}
Như bạn có thể thấy, mã này không được kết hợp chặt chẽ với các lớp hoặc các hệ thống khác, bởi vì nó chỉ sử dụng một số giao diện để làm công cụ. Điều này là tốt từ quan điểm của SoC.
Như bạn có thể thấy lớp này cũng chứa 3 phương thức riêng thực hiện một số công cụ ưa thích. Từ quan điểm SRP, những phương thức đó có lẽ nên được đặt trong một số lớp của riêng chúng. 2 trong số họ làm một cái gì đó với điều hướng, sẽ phù hợp với một số lớp INavulation. Cái kia thực hiện một số tính toán ưa thích trên một mặt hàng, điều này có thể được đặt trong một lớp IBusinessLogic.
Có một cái gì đó như thế này, cả hai bạn đều có SoC và SRP:
public class Foo
{
private readonly IValidator _validator;
private readonly IDataRetriever _dataRetriever;
private readonly IBusinessLogic _businessLogic;
private readonly INavigation _navigation;
public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
{
_validator = validator;
_dataRetriever = dataRetriever;
_businessLogic = businessLogic;
_navigation = navigation;
}
public NavigationObject GetDataAndNavigateSomewhereIfValid()
{
var data = _dataRetriever.GetAllData();
if(_validator.IsAllDataValid(data))
{
object b = null;
foreach (var item in data.Items)
{
b = _businessLogic.DoSomeFancyCalculations(item);
}
if(_validator.IsBusinessDataValid(b))
{
return _navigation.ValidBusinessLogic();
}
}
return _navigation.InvalidItems();
}
}
Tất nhiên bạn có thể tranh luận nếu tất cả logic này nên được đặt trong GetDataAndNavigateSomewhereIfValidphương thức. Đây là điều bạn nên tự quyết định. Đối với tôi có vẻ như phương pháp này đang làm quá nhiều thứ.
Đối với SRP chỉ được áp dụng ở cấp lớp, trong các cuốn sách của mình, Robert C. Martin (theo như tôi biết, ông đã phổ biến nếu không đưa ra khái niệm này):
Mã sạch, trang. 138 : "Nguyên tắc trách nhiệm duy nhất (SRP) nói rằng một lớp hoặc mô-đun nên có một, và chỉ một, lý do để thay đổi."
Trong Nguyên tắc, Mô hình và Thực tiễn Agile trong C #, trang 116 : "[...] và liên kết sự gắn kết với các lực khiến mô-đun hoặc lớp thay đổi."
Nhấn mạnh mỏ.
Trong APPP , anh ấy nói rất nhiều về SRP và tập trung gần như hoàn toàn vào cấp độ lớp học. Trong khi anh ta dường như tập trung vào cấp độ lớp học, tôi cảm thấy nguyên tắc này cũng được hướng đến các mô-đun và các cấu trúc cấp cao hơn khác.
Vì lý do như vậy, tôi sẽ không đủ điều kiện SRP là SoC ở cấp lớp như bạn đề xuất trong câu hỏi của bạn.
Ở đây bạn có thể tìm thấy một đoạn video ngắn giải thích rõ ràng sự khác biệt giữa các thuật ngữ đó. https://www.youtube.com/watch?v=C7hkrV1oaSY
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 ít chức năng chồng chéo nhất có thể. (Microsoft).
Phần quan tâm của người khác
Quan tâm của người Viking hoạt động ở cả cấp cao và cấp thấp
Nguyên tắc trách nhiệm duy nhất nêu rõ rằng mọi mô-đun hoặc lớp nên có trách nhiệm đối với một phần chức năng do phần mềm cung cấp và trách nhiệm đó phải được gói hoàn toàn bởi lớp. Tất cả các dịch vụ của nó nên được liên kết hẹp với trách nhiệm đó. (Định nghĩa Wikipedia)
Trách nhiệm của người khác
thay đổi những gì? “Một phần duy nhất của các chức năng được cung cấp bởi phần mềm” = Đơ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 ở cấp độ thấp
Tách mối quan tâm hoạt động ở cả cấp cao và cấp thấp
SRP và SoC làm việc cùng nhau để phân tách các mối quan tâm. Chúng giống hệt nhau ở cấp độ thấp
Dưới đây là sự hiểu biết của tôi về những nguyên tắc này.
Tách các mối quan tâm (SoC) - là về việc phân chia một hệ thống phần mềm thành các mô-đun nhỏ hơn, mỗi mô-đun này chịu trách nhiệm cho một mối quan tâm duy nhất. Một mối quan tâm, trong trường hợp này, là một tính năng hoặc trường hợp sử dụng của một hệ thống phần mềm. Một mô-đun có API (giao diện) được xác định rõ là kết quả làm cho toàn bộ hệ thống có tính gắn kết cao. Có hai loại chính: ngang và dọc.
Nguyên tắc trách nhiệm duy nhất (SRP) - là một nguyên tắc thiết kế nói rằng mỗi khối xây dựng (nó có thể là một lớp, một mô-đun, một đối tượng hoặc thậm chí là một chức năng) của một hệ thống chỉ nên có một trách nhiệm duy nhất. Robert C. Martin. Martin mô tả một trách nhiệm là một lý do để thay đổi. Nói chung, tốt hơn là có một lớp / đối tượng chịu trách nhiệm về một phần chức năng thay vì có thể thực hiện nhiều chức năng, đôi khi thậm chí không liên quan, làm cho lớp này lớn và được liên kết chặt chẽ, vì vậy- được gọi là đối tượng Thiên Chúa.
Ngoài ra tôi đã mô tả các nguyên tắc này chi tiết hơn trong bài viết trên blog của tôi, xin vui lòng xem xét.
https://crosp.net/blog/software-arch architecture / srp-soc-android-sinstall-example /