단일 책임 원칙 예제

단일 책임 원칙은 모든 모듈, 클래스 또는 함수[1]이 소프트웨어에서 제공하는 기능의 단일 부분에 대한 책임을 져야 하며, 그 책임은 전적으로 책임을 져야 한다는 컴퓨터 프로그래밍 원칙입니다. 클래스에 의해 캡슐화됩니다. 모든 서비스는 그 책임과 좁게 일치해야합니다. 로버트 시 마틴은 „반은 변화해야 할 이유가 하나뿐이어야 한다”[1] 비록 „이성”이라는 단어에 대한 혼란 때문에 최근에 „이 원리는 사람에 관한 것이다. (Actor)”[2] 컨트롤러가 주문 객체 저장, 이메일 전송 등을 포함하되 이에 국한되지 않는 „주문 하기”에 대해 너무 많이 알고 있는 방법 위의 코드 조각에 공지 그것은 단순히 단일 클래스에 대 한 너무 많은 작업. 약간의 변경마다 개발자는 전체 컨트롤러의 코드를 변경해야 합니다. 그리고 다른 컨트롤러도 주문을 만들어야하는 경우 개발자는 코드를 복사 붙여 넣기에 의존합니다. 컨트롤러는 전체 프로세스만 제어해야 하며 실제로 프로세스의 모든 논리를 수용하지 는 않습니다. 따라서 책임은 특정 배우에게 봉사하는 기능의 가족입니다. (로버트 시 마틴) 그렇다면 단일 책임 원칙과 응집력 사이의 관계는 무엇입니까? 응집력은 형식이 둘 이상의 책임을 소유하고 있는지 의심스러울 때 적용할 수 있는 공식적인 규칙을 제공합니다.

형식의 클라이언트가 해당 형식의 모든 함수를 항상 사용하는 경향이 있는 경우 형식은 매우 응집력이 있을 수 있습니다. 즉, 하나의 책임만 소유하고 있으므로 변경해야 하는 한 가지 이유만 있습니다. 코드 시스템에 필요한 모든 변경사항은 여러 지점에서 코드 본문을 변경해야 합니다. 시스템이 `같은 이유로 변경되는 것들을 함께 수집`이라는 원칙에 따라 구조화되면 변경해야 하는 모듈(클래스)의 수를 최소화할 수 있습니다. 이렇게 하면 캡슐화 경계 뒤에 가능한 한 변경 내용을 숨길 수 있으므로 변경 내용이 시스템의 나머지 부분으로 계단식으로 중단되는 것을 중지하고 손상될 수 있으므로 다시 테스트해야 하는 사항을 줄일 수 있습니다. 얼굴에, 이것은 상대적으로 간단 보인다. 프로그램 기능의 개별 조각은 외부 지원 없이 처리할 수 있는 개별 엔터티에 배포되어야 합니다. 그러나 프로그램의 „개별 조각”을 어떻게 정의합니까? 정확히 „책임”이란 무엇이며 비즈니스 관점에서 어떻게 추론합니까? „삼촌 밥”으로 널리 알려진 마틴은 2014 년 블로그 기사에서 관심있는 배우의 아이디어에 „책임”을 묶어 두었습니다[3].