srp 원칙 예제

코드 시스템에 필요한 모든 변경사항은 여러 지점에서 코드 본문을 변경해야 합니다. 시스템이 `같은 이유로 변경되는 것들을 함께 수집`이라는 원칙에 따라 구조화되면 변경해야 하는 모듈(클래스)의 수를 최소화할 수 있습니다. 이렇게 하면 캡슐화 경계 뒤에 가능한 한 변경 내용을 숨길 수 있으므로 변경 내용이 시스템의 나머지 부분으로 계단식으로 중단되는 것을 중지하고 손상될 수 있으므로 다시 테스트해야 하는 사항을 줄일 수 있습니다. SRP에 대해 기억해야 할 어려운 점은 코드 내의 종속성 이나 기능 적 관계가 아니라 변경 가능성이 있는 패턴을 기반으로 한다는 것입니다. 내부 구조나 코드의 외부 기능 및 요구 사항은 코드가 변경되는 비즈니스 환경의 특성이 아니라 키입니다. 마틴은 SRP의 사용 예를 제공 할 때 지속적으로 이러한 요인을 참조하지만 다른 해설자는 거의하지 않습니다. 그렇지 않으면 SRP를 사용하지 않는 작업을 수행합니다. 이는 오류를 수정하는 예입니다. 회귀 테스트를 수정하거나 에지 케이스를 처리하여 이 변경에 대한 수정 사항을 제공합니다. 단일 책임 원칙은 간단하고 직관적인 원칙이지만 실제로는 이를 올바르게 이해하기가 어려울 수 있습니다. 공개 원칙과 마찬가지로, 한 반이 단독으로 책임 원칙을 이행하는지 말할 수 없다는 것이 밝혀졌습니다. 들어오는 종속성을 확인해야 합니다. 즉, 클래스의 클라이언트는 전체 클래스인지 아닌지 정의합니다.

이 모든 원리들이 의미하는 바를 하나씩 이해해 봅시다. 붐. 간결하고 매력적이지만 모호합니다. 원칙을 설명하기 위해 작성자가 다음 클래스 다이어그램에 요약된 예제를 사용합니다. 그의 기사와 YouTube 강의 녹음의 많은 에서 그는 `변경 이유`에 대해 무엇을 의미하는지 설명합니다 , 급여를 계산하고보고하는 방법을 가진 직원에 대한 클래스, 또는 데이터 조작 및 데이터 지속성을 가진 클래스와 같은 예와 함께 작업. 그는 또한 소프트웨어가 제공하는 비즈니스 의 기능과 관련된 변경 이유에 대해 이야기합니다 : 이러한 경우 보고서가 필요한 비즈니스 기능과 급여를 계산하는 방법을 정의하는 비즈니스 함수가 있기 때문에 클래스를 분할해야합니다. 는 다릅니다.

カテゴリー: 未分類 パーマリンク