단일 책임 원칙과 우려 사항 분리의 차이점은 무엇입니까?
답변
SRP (Single Responsibility Principle)-각 클래스에 변경해야 할 한 가지 이유 만 제공하십시오. 및“변경 이유”==“책임”. 예 : 송장 클래스는 자체 인쇄 할 책임이 없습니다.
우려의 분리 (1974 년 이후). 우려 == 시스템의 특징. 각 우려 사항 처리 : 각 우려 사항에 대해 다른 우려 사항은 관련이 없습니다. 행동의 구현을 숨 깁니다.
에서 여기 .
답변
제 생각에는 단일 책임 원칙은 우려 사항 분리를 달성하기위한 도구 / 관용구 중 하나입니다.
답변
우려 사항과 단일 책임 원칙의 분리 (SoC vs SRP)
링크 된 기사에서 :
우려 사항 분리 (SoC) – 컴퓨터 프로그램을 가능한 한 기능이 겹치는 별개의 기능으로 분리하는 프로세스입니다. 관심사는 프로그램에 대한 관심이나 초점입니다. 일반적으로 관심사는 기능 또는 동작과 동의어입니다.
http://en.wikipedia.org/wiki/Separation_of_concerns
SRP (Single Responsibility Principle) – 모든 객체는 하나의 책임을 가져야하며 모든 서비스는 해당 책임과 협소하게 일치해야합니다. 어떤 수준에서 Cohesion은 SRP의 동의어로 간주됩니다.
http://en.wikipedia.org/wiki/Single_responsibility_principle
답변
단일 책임은 객체가 단일 작업 단위를 담당 함을 나타냅니다.
Seperation of Concerns는 기능이 가능한 한 적게 겹치는 모듈로 애플리케이션을 분할해야한다고 말합니다.
유사한 최종 결과 … 약간 다른 응용 프로그램.
답변
단일 책임 원칙과 우려 사항 분리는 실제로 동일합니다.
물론 당신은 둘 사이의 어떤 종류의 차이점을 알아 내려고하는 학문적 토론에서 수렁에 빠질 수 있습니다.하지만 그 이유는 무엇입니까? 모든 의도와 목적을 위해 그들은 동일한 것을 설명합니다. 가장 큰 문제는 사람들이 “우려”와 “책임”이 무엇인지 정확히 알고 싶어하는 데 너무 사로 잡혀 SRP와 SoC의 중요한 아이디어를 놓칠 수 있다는 것입니다.
그 아이디어는 단순히 코드베이스를 느슨하게 결합 된 분리 된 부분으로 나누는 것입니다. 이를 통해 여러 개발자가 서로 영향을주지 않고 서로 다른 부분에서 작업 할 수 있으며, 단일 개발자가 다른 부분을 손상시키지 않고 하나의 격리 된 부분을 수정할 수도 있습니다.
이는 모듈 수준에서 적용됩니다. 예를 들어 MVC는 SRP 및 SoC를 촉진하는 아키텍처 패턴입니다. 코드베이스는 격리 된 모델, 뷰 및 컨트롤러로 분할됩니다. 이렇게하면 모델과 관계없이 뷰를 수정할 수 있습니다. 둘 둘은 끔찍하게 얽혀 있지 않습니다.
낮은 수준에서 이것은 수업에도 적용되어야합니다. 단일 클래스에 수십 개의 메서드를 넣는 대신 코드를 여러 개로 나눕니다. 같은 이유로.
또한 메서드 수준에서도 큰 메서드를 작은 메서드로 분할합니다.
원칙적으로. SRP는 규칙이 아니라 원칙이므로 종교적으로 극단적으로 따를 필요가 없습니다 (읽을 수 없음 / 안됨). 예를 들어 너무 멀리 가고 각 클래스에 7 줄 메서드가 하나만있는 것은 아닙니다. 코드를 분리 된 부분으로 나누는 일반적인 원칙을 의미합니다. 요점은 더 나은 코드베이스와 더 안정적인 소프트웨어로 이어질 것입니다.
답변
우려 사항 분리 (SoC).가능한 한 기능이 거의 겹치지 않도록 애플리케이션을 별개의 기능으로 나눕니다. (마이크로 소프트).
“관심”= “고유 한 기능”= “고유 한 섹션”
“우려”는 높은 수준과 낮은 수준 모두에서 작동합니다.
단일 책임 원칙에 따르면 모든 모듈 또는 클래스는 소프트웨어가 제공하는 기능의 단일 부분에 대한 책임이 있어야하며 해당 책임은 클래스에 의해 완전히 캡슐화되어야합니다. 모든 서비스는 그 책임과 좁게 일치해야합니다. (Wikipedia 정의)
“책임”=“변경 이유”무엇을 변경 합니까? “소프트웨어가 제공하는 기능의 단일 부분”= 기본 단위
결론
-
단일 책임 원칙은 기본 단위에서 작동-> 낮은 수준에서 작동
-
우려 사항 분리는 높은 수준과 낮은 수준 모두에서 작동합니다.
-
SRP와 SoC는 함께 문제를 분리합니다. 그들은이다
정확하게 낮은 수준에서 동일
답변
이전 답변 중 Single Responsibility Principle 을 만든 Robert Martin의 인용문이 없기 때문에 여기에 더 권위있는 답변이 필요하다고 생각합니다.
SRP에 대한 Martin의 영감은 David Parnas, Edsger Dijkstra ( Concerns 라는 용어를 만들었습니다 ) 및 Larry Constantine ( Coupling and Cohesion 이라는 용어를 만들었습니다) 에서 영감을 얻었습니다 . Martin은 아이디어를 SRP에 통합했습니다.
단일 책임 원칙에 대한 또 다른 표현은 다음과 같습니다.
같은 이유로 변하는 것들을 모으십시오. 다른 이유로 변경되는 것들을 분리하십시오.
이것에 대해 생각해 보면 이것이 응집력과 결합을 정의하는 또 다른 방법이라는 것을 알게 될 것입니다. 우리는 같은 이유로 변화하는 것들 사이의 응집력을 높이고, 다른 이유로 변화하는 것들 사이의 결합을 줄이고 싶습니다.
그러나이 원칙에 대해 생각할 때 변화의 이유는 사람 이라는 것을 기억하십시오 . 그것은이다 사람들 의 변경을 요청합니다. 그리고 당신은 많은 다른 사람들이 다른 이유로 관심을 갖는 코드를 함께 혼합함으로써 그 사람들이나 자신을 혼동하고 싶지 않습니다.
원래 질문에 대해 SRP와 SoC의 사소한 차이점은 Martin 이 사람들 을 지칭하기 위해 관심사 라는 용어를 정제했다는 것 입니다.
