SOLID responsibility

x·2021년 3월 27일
0

responsibility

  • 클래스는 하나의 책임을 가져야 한다
    • 클래스에 여러 메서드가 있는 경우는? 메서드가 증가한다고 해서 책임이 증가하는 건 아님. 같은 부류의 메서드라면 책임의 수에 영향이 없다
    • 부류 : 메서드의 클라이언트에 의해 결정, 누가 해당 메서드의 변경을 유발하는 사용자인가
    • 사용자에 따라 메서드 부류를 나눈다
  • 단일책임원칙은 사용자에 관한 것이다
  • 책임
    • SW의 변경을 요청하는 특정 사용자들에 대해 클래스, 함수가 갖는 것
    • 특정 액터의 요구사항을 만족시키기 위한 일련의 함수의 집합
    • 액터의 요구사항 변경이 일련의 함수들의 변경의 근원이 된다.
    • 변경의 근원
      * 원인이 같으면 같은 책임으로 볼 수 있다
      클래스 변경을 하는 사용자들을 역할에 따라 나눠야 한다. 유저가 특정 역할을 수행할 때 액터라고 한다. 책임은 개인이 아니라 액터에 연결한다.

SW의 두가지 가치

첫번째 가치와 두번째 가치가 있다
두번째 가치는 현재 SW가 현재 사용자의 현재 요구사항을 만족하는가?이다
첫번째 가치는 지속적으로 변화하는 요구사항을 수용하는 것이다. 대부분의 SW는 현재의 요구사항을 만족하지만 변경하긴 어렵다.

collision

여러가지 책임을 하나의 클래스에 넣으면 충돌이 발생하고 첫번째 가치가 저하된다. 여러 액터가 한 클래스의 변경을 원하면 하나의 클래스에서 여러 코드 변경이 일어나고 소스코드 충돌이 생긴다

fan out 출력이 얼마나 많이 입력으로 사용되는가

클래스가 많은 책임을 가지면 변경에 민감해진다. 책임을 줄여야 한다. 즉 하나의 클래스는 하나의 책임을 가져야한다.

SRP

  • 모듈은 반드시 하나의 변경 사유(클래스 사용하는 액터)를 가져야한다.
  • 시스템 설계
    • 액터 파악에 주의해야함
    • 책임 식별
    • 하나의 책임을 하나의 모듈에 할당
    • 분리 이유
      • 다른 액터에 의해 변경되면 안되기 때문

solution

다양한 방법이 존재한다.
1. 의존성 역전

  • 클래스를 클래스와 인터페이스로 분리한다.
  • 액터를 클래스에서 디커플한다.
    • 모든 액터들이 하나의 인터페이스에 결합
    • 구현은 하나의 클래스에서 일어난다
  1. extract class
  • 클래스를 분리한다
  • 액터들은 각 클래스에 의존한다
  • 각 책임에 대한 구현은 분리된다
  • 각 책임 변경에 따른 영향이 다른 책임에 없다
  • 문제점
    • 하나였던 클래스 개념이 분리됨
  1. facade - 어디에 구현이 있는지 찾기 쉽게
  • 메서드를 파사드 클래스에 넣고 하위 클래스에 각 메서드를 위임한다.
  • 어디에 구현됐는지 찾기는 쉽지만 액터들은 결합되어 있다
    • 결합을 끊으려면 인터페이스가 있어야함
  1. interface segregation
  • 각 책임에 대한 인터페이스를 만든다
  • 각 인터페이스를 하나의 클래스로 구현한다
  • 액터들은 디커플되지만 어디에 구현됐는지 찾기 어렵다. 하나의 클래스에 구현되어 구현은 결합된다.

faking it

처음부터 설계할 때 다이어그램을 완전하게 그리지 않고 테스트부터 작성해서 코드를 짜고 리팩토링한다. 원하는 결과가 나올 때까지 테스트를 성공시킨다. 테스트를 확보한 후 리팩토링한다. 액터를 식별하고 클래스를 분리시킨다. 다이어그램을 그린다. 다이어그램을 그리기 가장 좋은 때는 완료된 이후다.

https://www.youtube.com/watch?v=AdANHDp5dTM

0개의 댓글