SRP (Single Responsibility Principle)가 목표입니까?


17

"사용자에게 매력적인"디자인을 디자인하려는 두 명의 UI 디자이너를 고려하십시오. "사용자 매력"은 객관적이지 않으며 디자이너의 마음에만있는 개념입니다. 따라서 디자이너 A는 예를 들어 빨간색을 선택할 수 있지만 디자이너 B는 파란색을 선택할 수 있습니다. 디자이너 A는 디자이너 B와 완전히 다른 레이아웃을 만듭니다.

나는 SRP (Single Responsibility Principle)에 대해 읽었으며 내가 이해 한 것은 일종의 주관적인 분석이나 OO 디자이너에서 다른 OO 디자이너에 이르기까지 다양한 책임을 분석 한 것입니다. 내가 맞아? 다시 말해, SRP 교장을 기반으로 한 시스템에 대해 서로 다른 두 가지 디자인을 제안하는 두 가지 우수한 객체 지향 분석기와 디자이너를 보유 할 수 있습니까?


4
나는 모든 종류의 디자인 (예술, 공학, ...)이 객관성과 주관성의 균형을 가지고 있다고 생각합니다. 어떤 명확한 규칙과 제약, 경험과 판단 요구, 심지어는 완전히 무료 인 모든 옵션이 좋았습니다. 서로의 선택.
Steve314

답변:


12

좋은 질문이자 자주 사용했던 질문입니다.

나는 객관적이지 않다고 말할 것이다. 확실히 주관적입니다. 문제를 해결하는 방법은 해당 유형의 문제에 대한 철학에 달려 있습니다. 과학은 우리에게 동일한 문제를 효과적으로 해결하는 방법은 여러 가지가 있음을 보여줍니다. 과학은 또한 대륙을 떠나 사람들이 독립적으로 동일한 솔루션을 만들 수 있으므로 일부 솔루션은 다른 솔루션보다 더 분명하다는 것을 보여줍니다. 어쨌든 "최고"의 관점에서 솔루션을 판단하는 것은 귀하의 기준에 달려 있습니다.

실제로, 하나는 동일한 전체의 두 부분으로 볼 수 있고 다른 하나는 완전히 별개의 개념으로 볼 수 있습니다. 다른 코드 라이브러리의 관리자가 동일한 문제에 접근하는 방법을 볼 때 항상 이것을 알 수 있습니다. 그러나 두 솔루션 모두 제대로 작동합니다.

(PS. OP의 최종 질문이 질문 제목의 반대를 요구함에 따라이 답변을 편집했습니다.)


5

원칙 자체는 객관적이지만 원칙을 따르는 무언가를 구현하는 방법은 매우 다양하므로 두 명의 독립 개발자가 거의 항상 동일한 응용 프로그램에 대해 서로 다른 시스템 설계를 생각해냅니다.

동일한 개발자가 동일한 디자인을 두 번 수행해도 여전히 적어도 부분적으로 다른 두 가지 솔루션이 나올 것입니다.

시스템 설계를 항상 동일하게 보이게하려면 원칙적으로 설계 결정의 모든 측면을 다루어야합니다. 단일 책임 원칙은 시스템 설계와 관련된 설계 결정의 일부만 다룹니다.


좋은 분석 @ 구파. +1. 나는 모든 것을 포괄하지 않는 아이디어를 좋아했습니다. 예, SRP는 하나의 문제에 대해 모든 책임을 져야한다고 말합니다. 그러나 책임의 경계가 어디인지는 알려주지 않습니다.
Saeed Neamati

2

원칙의 적용은 주관적입니다. 그러나 "주관적"은 미학과 같은 방식으로 "선호"와 동일하지 않습니다.

명백한 극단이 있습니다. 다른 클래스를 호출하지 않는 몇 줄의 코드만으로 정확히 하나의 메소드가있는 클래스는 확실히 SRP를 따릅니다. 반면, 원시 소켓을 통한 완전한 전자 메일 구현을 포함하는 클래스와 GUI 양식을 작성하는 두 가지 메소드가있는 클래스 는 SRP를 따르지 않습니다 .

미학은 비유가 좋지 않습니다. 더 나은 유추는 결합응집력 의 잘 알려진 컴퓨터 과학 개념 일 것이다. 이들 중 어느 것도 흑백, 참 또는 거짓 속성이 아닙니다. 그러나 그들은 이다 질적 요소가 경우에도, 측정. 숙련 된 개발자 그룹에게 동일한 기능에 대한 두 개의 개별 디자인을 보여 주면 디자인에 더 많은 결합 및 / 또는 응집력이있는 유사한 판독 값을 제공하게됩니다.

실제로, SRP는 본질적으로 단지 기능적인 응집력입니다. 일부 모듈 (예 : 클래스)의 일부는 모두 같은 기능을 수행하는 데 기여하므로 다른 이유없이 함께 그룹화해야합니다. "함수"는 해석의 대상이 될 수 있습니다. 어떤 사람들은 이것을 문자 그대로 단일 기능 (또는 방법 또는 절차) 선언 으로 해석 할 수도 있고 , 다른 사람들은 조금 뒤로 물러나서 기능을 "전자 메일 보내기"또는 "음악 재생"으로 생각할 수도 있습니다. 그러나 여전히 기동 할 공간이 너무 많습니다. "물건 관리" 는 유효한 기능적 설명이 아닙니다.


0

"책임"은 "변경 이유"로 객관적으로 정의되어 있습니다. 프로그래밍 당시에는 변경해야 할 모든 이유가 미래에 있기 때문에 프로그래머는 자신의 경험과 영역 지식만으로 추측 할 수 있습니다. 따라서 책임을 분석하는 것은 부분적인 주관적인 일종의 예측입니다.


0

SRP는 객관적입니다. 구현은 주관적이다

동일한 기능을 가진 두 가지 구현은 완전히 다른 내부 구조를 사용하여 클래스와 방법이 다르며 SRP를 충족시킬 수 있습니다.

이들이 동일한 방법과 상태를 사용하고 둘 다 정규화 (최소 / 중복되지 않은) 경우 이론적으로 SRP에서 동일한 클래스와 방법으로 끝납니다.

그러나 나는 그것을 증명할 수 없다. 아직.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.