a) SRP 와 SoC 의 차이점은 무엇입니까 ? 아마도 그 SRP는 동안, 클래스 레벨로인가 의 SoC가 적용 가능 시스템 , 서브 시스템 , 모듈 , 클래스 또는 함수 레벨.
B)에 대한 답변을하는 경우 A는) 다음 예이다 의 SoC가 적용 클래스 수준 의 동의어 SRP를 ?
감사합니다
a) SRP 와 SoC 의 차이점은 무엇입니까 ? 아마도 그 SRP는 동안, 클래스 레벨로인가 의 SoC가 적용 가능 시스템 , 서브 시스템 , 모듈 , 클래스 또는 함수 레벨.
B)에 대한 답변을하는 경우 A는) 다음 예이다 의 SoC가 적용 클래스 수준 의 동의어 SRP를 ?
감사합니다
답변:
Single Responsibility Principle은 하나의 코드 만 수행하는 코드에 관한 것으로, 모든 기능을 여러 클래스로 나눌 수 있습니다. 예를 들어 유효성 검사, 비즈니스 로직 수행, 모델 보강, 데이터 검색, 데이터 업데이트, 탐색 등의 특정 클래스가 있습니다.
우려의 분리는 코드가 다른 클래스 / 시스템과 밀접하게 연결되지 않은 것에 관한 것입니다. 코드에서 인터페이스를 사용하면 클래스 / 시스템을 코드에 느슨하게 연결할 수 있습니다. 이것의 장점은 코드를 단위 테스트하는 것이 더 쉽다는 것입니다. 이를 달성하는 데 도움이되는 많은 (IoC) 프레임 워크가 있지만 물론 그러한 것을 직접 구현할 수도 있습니다.
SoC가 있지만 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();
}
}
보시다시피이 코드는 클래스 나 다른 시스템과 밀접하게 연결되어 있지 않습니다. 일부 인터페이스 만 사용하기 때문입니다. 이것은 SoC 관점에서 좋습니다.
보시 다시피이 클래스에는 멋진 작업을 수행하는 3 개의 개인 메소드가 포함되어 있습니다. SRP 관점에서 볼 때 이러한 방법은 자체 클래스에 배치해야합니다. 그들 중 2 명은 일부 탐색 클래스에 적합한 탐색 기능을 수행합니다. 다른 하나는 항목에 대한 멋진 계산을 수행하며, 이는 아마도 IBusinessLogic 클래스 내에 배치 될 수 있습니다.
이와 같은 것을 갖추면 SoC와 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();
}
}
물론이 모든 논리를 GetDataAndNavigateSomewhereIfValid메소드에 배치해야하는지 토론 할 수 있습니다 . 이것은 스스로 결정해야 할 것입니다. 나 에게이 방법은 너무 많은 일을하고있는 것처럼 보입니다.
SRP가 수업 수준에서만 적용되는 경우, 그의 책 Robert C. Martin (그가 개념을 생각해 내지 않으면 대중화했습니다)은 다음과 같이 말합니다.
클린 코드, 페이지. 138 : "SRP (Single Responsibility Principle)는 클래스 또는 모듈에 변경 해야 할 단 하나의 이유가 있어야한다고 명시하고 있습니다."
C #의 Agile Principles, Patterns and Practices, 116 페이지 : "[...] 및 응집력을 모듈 또는 클래스를 변경 시키는 힘과 연관시킵니다 ."
강조합니다.
에서 APPP 그는 SRP에 대해 더 큰 길이 이야기와 클래스 수준에 거의 전적으로 초점을 맞추었다. 그는 수업 수준에 초점을 맞추는 것처럼 보이지만 그 원리는 모듈 및 기타 더 높은 수준의 구성에 관한 것입니다.
그런 이유로 귀하의 질문에서 제안하는 것처럼 SRP를 클래스 수준에서 SoC로 인정하지 않습니다.
여기에서 이러한 용어의 차이점을 명확하게 설명하는 짧은 비디오를 찾을 수 있습니다. https://www.youtube.com/watch?v=C7hkrV1oaSY
우려 분리 (SoC). 기능이 거의 겹치지 않도록 애플리케이션을 고유 한 기능으로 나눕니다. (Microsoft).
“문제”=“고유 한 특징”=“고유 한 부분”
“관심”은 높은 수준과 낮은 수준 모두에서 작동합니다
단일 책임 원칙 은 모든 모듈 또는 클래스가 소프트웨어가 제공하는 기능의 단일 부분에 대해 책임을 가져야하며 해당 책임은 클래스에 의해 완전히 캡슐화되어야한다고 명시합니다. 모든 서비스는 그 책임과 좁게 조정되어야합니다. (위키 백과 정의)
"책임"= "변경 사유"
뭘 바꿔? “소프트웨어가 제공하는 기능의 단일 부분”= 기본 장치
결론
단일 책임 원칙은 기본 단위에서 작동-> 낮은 수준에서 작동
우려의 분리는 높은 수준과 낮은 수준 모두에서 작동합니다.
SRP와 SoC는 문제 분리를 위해 함께 작동합니다. 그들은 낮은 수준에서 정확히 동일합니다
다음은 이러한 원칙에 대한 이해입니다.
SoC (Separation of Concerns) — 소프트웨어 시스템을 더 작은 모듈로 나누는 것입니다. 각 모듈마다 하나의 관심사가 있습니다. 이 경우 문제는 소프트웨어 시스템의 기능 또는 사용 사례입니다. 모듈은 잘 정의 된 API (인터페이스)를 가지고있어 전체 시스템의 응집력을 높입니다. 가로와 세로의 두 가지 주요 유형이 있습니다.
SRP (Single Responsibility Principle) — 시스템의 각 빌딩 블록 (클래스, 모듈, 객체 또는 기능 일 수 있음)은 단일 책임 만 가져야한다는 설계 원칙입니다. 로버트시 마틴 Martin은 책임을 변화의 이유로 설명합니다. 일반적으로, 때로는 관련이없는 많은 기능을 수행 할 수있는 대신 기능의 단일 부분에 대해 책임이있는 단일 클래스 / 객체를 갖는 것이이 클래스를 크고 밀접하게 결합시키는 것이 훨씬 좋습니다. “신의 대상”이라고
또한 블로그 원칙에 이러한 원칙을 자세히 설명했습니다.
https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/