단일 책임 원칙과 우려 사항 분리의 차이점

단일 책임 원칙과 우려 사항 분리의 차이점

---

단일 책임 원칙과 우려 사항 분리의 차이점은 무엇입니까?

---

SRP (Single Responsibility Principle)-각 클래스에 변경해야 할 한 가지 이유 만 제공하십시오. 및“변경 이유”==“책임”. 예 : 송장 클래스는 자체 인쇄 할 책임이 없습니다.

우려의 분리 (1974 년 이후). 우려 == 시스템의 특징. 각 우려 사항 처리 : 각 우려 사항에 대해 다른 우려 사항은 관련이 없습니다. 행동의 구현을 숨 깁니다.

에서 여기 .

---

우려 사항과 단일 책임 원칙의 분리 (SoC vs SRP)

링크 된 기사에서 :

우려 사항 분리 (SoC) – 컴퓨터 프로그램을 가능한 한 기능이 겹치는 별개의 기능으로 분리하는 프로세스입니다. 관심사는 프로그램의 관심 또는 초점입니다. 일반적으로 관심사는 기능 또는 동작과 동의어입니다. http://en.wikipedia.org/wiki/Separation_of_concerns

SRP (Single Responsibility Principle) – 모든 객체는 하나의 책임을 가져야하며 모든 서비스가 해당 책임과 좁게 조정되어야합니다. 어떤 수준에서 응집력은 SRP의 동의어로 간주됩니다. http://en.wikipedia.org/wiki/Single_responsibility_principle

---

단일 책임은 객체가 단일 작업 단위를 담당 함을 나타냅니다.

Seperation of Concerns는 기능이 가능한 한 적게 겹치는 모듈로 애플리케이션을 분할해야한다고 말합니다.

유사한 최종 결과 ... 약간 다른 응용 프로그램.

---

제 생각에는 단일 책임 원칙은 우려 사항 분리를 달성하기위한 도구 / 관용구 중 하나입니다.

---

단일 책임 원칙과 우려 사항 분리는 실제로 동일합니다.

물론 당신은 둘 사이의 어떤 종류의 차이점을 알아 내려고하는 학문적 토론에서 수렁에 빠질 수 있습니다.하지만 그 이유는 무엇입니까? 모든 의도와 목적을 위해 그들은 동일한 것을 설명합니다. 가장 큰 문제는 사람들이 "우려"와 "책임"이 무엇인지 정확히 알고 싶어하는 데 너무 사로 잡혀 SRP와 SoC의 중요한 아이디어를 놓칠 수 있다는 것입니다.

그 아이디어는 단순히 코드베이스를 느슨하게 결합 된 분리 된 부분으로 나누는 것입니다. 이를 통해 여러 개발자가 서로 영향을주지 않고 서로 다른 부분에서 작업 할 수 있으며 단일 개발자가 다른 부분을 손상시키지 않고 하나의 분리 된 부분을 수정할 수 있습니다.

이는 모듈 수준에서 적용됩니다. 예를 들어 MVC는 SRP 및 SoC를 촉진하는 아키텍처 패턴입니다. 코드베이스는 격리 된 모델, 뷰 및 컨트롤러로 분할됩니다. 이렇게하면 모델과 관계없이 뷰를 수정할 수 있습니다. 두 둘은 끔찍하게 얽혀 있지 않습니다.

낮은 수준에서 이것은 수업에도 적용되어야합니다. 단일 클래스에 수십 개의 메서드를 넣는 대신 코드를 여러 개로 나눕니다. 같은 이유로.

또한 메서드 수준에서도 큰 메서드를 작은 메서드로 분할합니다.

원칙적으로. SRP는 규칙이 아니라 원칙이므로 종교적으로 극단적으로 따를 필요가 없습니다 (읽을 수 없음 / 안됨). 예를 들어 너무 멀리 가고 각 클래스에 하나의 7 줄 메서드 만있는 것은 아닙니다. 코드를 분리 된 부분으로 나누는 일반적인 원칙을 의미합니다. 요점은 더 나은 코드베이스와 더 안정적인 소프트웨어로 이어질 것입니다.

---

우려 사항 분리 (SoC). 가능한 한 기능이 거의 겹치지 않도록 애플리케이션을 별개의 기능으로 나눕니다. (Microsoft).

"관심"= "고유 한 기능"= "고유 한 섹션"

“우려”는 높은 수준과 낮은 수준 모두에서 작동합니다.

단일 책임 원칙  은 모든 모듈 또는 클래스가 소프트웨어에서 제공하는 기능의 단일 부분에 대한 책임을 가져야하며 해당 책임은 클래스에 의해 완전히 캡슐화되어야한다고 명시합니다. 모든 서비스는 그 책임과 좁게 조정되어야합니다. (Wikipedia 정의)

“책임”=“변경 이유”무엇을 변경 합니까? "소프트웨어가 제공하는 기능의 단일 부분"= 기본 단위

결론

• 단일 책임 원칙은 기본 단위에서 작동-> 낮은 수준에서 작동

• 우려 사항 분리는 높은 수준과 낮은 수준 모두에서 작동합니다.

• SRP와 SoC는 함께 문제를 분리합니다. 그들은이다
  정확하게 낮은 수준에서 동일

---

우려 사항 분리는 프로세스입니다. Single Responsibility Principle은 설계 / 건축 철학입니다. 완전히 분리되어 있지는 않지만 다른 용도로 사용됩니다.

---

이전 답변 중 Single Responsibility Principle 을 만든 Robert Martin의 인용문이 없기 때문에 여기에 더 권위있는 답변이 필요하다고 생각합니다.

SRP에 대한 Martin의 영감은 David Parnas, Edsger Dijkstra ( Concerns 라는 용어를 만들었습니다 ) 및 Larry Constantine ( Coupling and Cohesion 이라는 용어를 만들었습니다) 에서 영감을 얻었습니다 . Martin은 아이디어를 SRP에 통합했습니다.

단일 책임 원칙에 대한 또 다른 표현은 다음과 같습니다.

같은 이유로 변하는 것들을 모으십시오. 다른 이유로 변경되는 것들을 분리하십시오.

이것에 대해 생각해 보면 이것이 응집력과 결합을 정의하는 또 다른 방법이라는 것을 알게 될 것입니다. 우리는 같은 이유로 변화하는 것들 사이의 응집력을 높이고, 다른 이유로 변화하는 것들 사이의 결합을 줄이고 싶습니다.

그러나이 원칙에 대해 생각할 때 변화의 이유는 사람 이라는 것을 기억하십시오 . 그것은이다 사람들 의 변경을 요청합니다. 그리고 당신은 많은 다른 사람들이 다른 이유로 관심을 갖는 코드를 함께 혼합함으로써 그 사람들이나 자신을 혼동하고 싶지 않습니다.

원래 질문에 대해 SRP와 SoC의 사소한 차이점은 Martin 이 사람들 을 지칭하기 위해 관심사 라는 용어를 정제했다는 것 입니다.

---

유사하지만 : SoC는 관심사와 관련이 있습니다. 복잡한 문제를 여러 관심사로 나누기 위해 SRP는 단 하나의 책임 만 갖습니다.

---

SRP와 SOC는 서로 다른 추상화 수준에서 작동합니다. 목적은 두 경우 모두 결합을 줄이고 응집력을 강화하는 것입니다. SRP는 객체 수준에서 더 많이 작동하지만 SOC는 기능 수준의 구현에서도 작동 할 수 있습니다. 함수는 하나의 객체로 구현 될 수 있지만 여러 객체로도 구현 될 수 있습니다. 따라서 두 원리의 결합과 응집력이 다를 수 있습니다.

---

관심사 분리 (SoC)와 단일 책임 원칙 (SRP)을 비교해 보았습니다.

차이점

• The SRP is at the class level, but SoC is in each computer program, abstraction ... or sometimes architectural level.

• The SRP is about the quality of (how not what) dividing your domain into cohesive classes which have just one responsibility (one reason to change). In other side, SoC is a design principle for separating a context into distinct sections, such that each section addresses a separate concern(what not how), as there are a lot of tools (for example classes, functions, modules, packages, ...) to reach this goal different levels.

• The concept of SRP is based on the cohesion (high cohesion), whereas SoC is close to Molecularity, divide and conquer (D&C), ... in each level of abstraction.

• SoC is a good design principle to cope complexity, such as abstraction whereas to reach single responsible classes you can use SoC principle as a great solution. As, a way to know that a class has more than one responsibility is if you can extract another responsibility(concern) from that class.

Similarities

• After applying each of these principles, your context becomes more reusable, maintainable, robust, readable, ... .

---

Answer:

Separation of Concerns (SoC) is a more versatile term - it can be applied at the system level or at lower levels such as classes (or even the methods within a class)

Single Responsibility Principle (SRP) is used to discuss SoC at the lower levels e.g. in a class

---

Ways to think about it:

1. At the low level, SoC and SRP are synonymous. So you could say SRP is a redundant term - or that SoC should only be used to discuss the system level

2. Given (1), the term SoC is somewhat ambiguous. You need context to know whether the discussion is about high level SoC or lower level SoC

3. To remember that SRP is the term for only lower levels, think of this: in everyday language, a "responsibility" is usually a well-defined thing that can be tied to specific code, whereas "concerns" are usually kind of vague and may encompass a bunch of related things, which is perhaps why SoC is a more natural fit for discussing the system level than is SRP

4. SoC is in some sense a stronger requirement/principle than SRP because it applies at the system level, and to be truly achieved at the system level must also be used in the development of the system components. That is, a high level of SoC implies decent SoC/SRP at the lower levels - but the reverse is not true, that is, lower level SoC/SRP does not imply SoC or anything at all for the next higher level, never mind the encompassing system. For an example of SoC/SRP that is achieved at the method level, but then violated at the class level, check out this Artur Trosin's blog post.

참고URL : https://stackoverflow.com/questions/1724469/difference-between-single-responsibility-principle-and-separation-of-concerns