객체지향 설계 5원칙 SOLID 1. 단일책임원칙 (SRP)

객체 지향 원칙 설계의 5원칙은 

1. SRP  : 단일 책임 원칙

2. OCP : 개방 폐쇄 원칙

3. LSP  : 리스코프 치환 원칙

4. ISP : 인터페이스 분리 원칙

5. DIP  : 의존 역전 원칙 

이 있다.

그 중 첫번째 원칙, SRP에 대해 알아보겠다.

---

단일책임원칙 (SRP : SingleResponsibilityPrinciple)

---

클래스를 변경하는 이유가 단 한가지 여야 한다.

 

단일 책임 원칙은 SRP, Single Responsibility Principle 즉, 단일 책임원칙이다. 

객체지향에서 지켜야 할 원칙 중 하나이며, 하나의 클래스가 하나의 책임만을 가지고 있어야 한다. 라는 것이다. 

 

하지만 언뜻 보면 하나의 클래스가 하나의 역할만을 해야 한다 라는 뜻으로 오해할 수 있다. 

이런 의미가 아니라 하나의 클래스가 하나의 액터! 한 기능만을 담당해야 한다는 것이다. 

        ->  여기서 액터란 클래스를 변화시킬 수 있는 주체를 말한다. 

```

즉, 메소드의 개수가 책임의 개수가 아니라 
하나의 모듈은 하나의 일만 해야 한다는 의미다!

```

 

SRP를 위반한 코드

pulic class Employee {
	private String name;
    private String position;
    
    public Employee (name, position) {
    	this.name = name;
        this.position = position;
    }
    
    void calculateExtraHour() { }
    
    void calculatePay() { //급여 계산 메소드
		calculateExtraHour();
    }
    void reportHours() { //근무 시간 계산 메소드
    	calculateExtraHour();
    }
    void save() { } //변경된 정보 DB에 저장하는 메소드
    
}

 

위에서 메소드가 세개 있다 

1. calculatePay() 는 회계팀에서 사용하는 급여를 계산하는 메소드

2. reportHours() 는 인사팀에서 근무시간을 계산하기 위한 메소드 

3. save() 는 기술팀에서 변경된 정보를 저장하기 위해 사용하는 메소드

 

즉, Employee 클래스에서는 3개의 액터가 존재한다는 것이다. 

이를 해결하기 위한 방법으로는 Facade Pattern 이 있다.

 

Facade Pattern (퍼사드 패턴) 

Facade 란 건물의 정면을 뜻한다.

즉, Facade Pattern 은 말 그대로 건물의 뒷부분을 보여주지 않고, 정면만 보여주는 패턴이라는 것이다. 

이제 위 코드에 이 패턴을 적용시켜 보자 

public class EmployeeFacade {
	private String name;
    private String position;
    
    public EmployeeFacade (name, position) {
		this.name = name;
        this.position = position;
    }
    PayCalculator calculatePay() {
    	return new PayCalculator().calculatePay(); 
    }
    HourReporter reportHours() {
    	return new HourReporter().reportHours();
    }
    EmployeeSaver save() {
    	return new EmployeeSaver().save();
    }
}

public class PayCalculator {
	calculateExtraHour() {}
    calculatePay() {
    	calculateExtraHour();
    }
}

public class HourReporter{
	calculateExtraHour() {}
    reportHours() {
    	calculateExtraHour();
    }
}

publlic class EmployeeSaver{
	save(){}
}

이렇게 분리하게 되면 EmployeeFacade 클래스에서는 로직이 구현되지 않는다. 

단지 각 클래스의 메소드를 불러와 사용하는 역할만 하게 된다. 

 

즉, 메소드의 구현이 어떻게 되어있는지 건물의 뒷부분은 보여주지 않고

어떤 메소드가 있는지 건물의 정면만을 보여주며

각 메소드의 구현은 각 클래스에 위임하는 것이다. 

 

이렇게 구현하게 되면 변경사항이나 오류가 생겼을 때 

그 기능의 구현 클래스로 가 변경하면 되기 때문에 EmployeeFacade 클래스는 변경이 생기지 않게 된다. 

다른 클래스에 전혀 영향을 주지 않게 되는 것이다. 

 

따라서 단일 책임 원칙은 하나의 클래스가 하나의 엑터만을 담당해야 한다! 

---

단일 책임 원칙을 사용해야 하는 이유 

1. 특정 기능을 수정할 때 하나의 클래스만 수정하면 되기 때문에 유지보수가 편리하다.

2. 기능 수정 시 발생할 수 있는 사이드 이펙트를 줄일 수 있다. 

3. 단일 클래스의 기능이 적어져 종속성이 줄어든다. 

4. 작고 잘 조직된 클래스는 검색과 이해가 쉽다. 

5. 하나의 책임만을 가지기 때문에 구현 및 이해가 쉽다.

 

하지만, 프로젝트의 규모가 커지면 기존 코드보다 길어질수있다는 단점을 가지고 있어 

SRP를 사용하는것이 한계가 존재할것이다. 

이때에는 여러개의 클래스를 사용하는 것이 유지보수와 의미 파악 측면에서 더 유리할 수 있기 때문에 

설계 시 잘 고려해서 설계해주어야 한다.