본문 바로가기

카테고리 없음

OOP SOLID 원칙 1. SRP

SRP (Single Responsibility Principle)의 정의는 "Class should have one reason to change." 이다. (Robert C. Martin에 의해서 정의)

즉, 한글로 풀어쓰면 "클래스는 하나의 책임을 가져야 하며 그 책임에 대한 이유로 변경되어야 한다." 이다.

약간 아리송할지 모르겠으나 OOP 원칙중 그나마 가장 직관적인 원칙이다...!


여기서 책임이라 함은 클래스가 하는 역할이라 생각하면 편하다.

클래스의 역할은 클래스의 메소드로 표현된다. (특징은 데이터!)

즉, 하나의 클래스는 일관된 기능을 가진 메소드들을 가져야 한다는것이다.


간단한 예로 자전거 클래스가 있고 그 자전거 클래스는 바퀴 클래스를 가지고 있고 그 바퀴의 역할은 '구르기'라고 정해보자

바퀴 클래스의 역할은 그야말로 앞으로 구르거나 뒤로 구르면 된다! 그러면 바퀴 클래스는 그저 roll 메소드를 가지면 된다. 혹은 forward, backword 정도..?


Class Wheel {

public :

void roll () {

...

}


void fly () {

...

}

};


만약에 바퀴 클래스가 fly와 roll 메소드를 가지고 있다고 생각해보자. (뭔가 이상함을 느껴야 정상이다.)

일단 상식적으로 바퀴를 이용하여 날지 못하는건 사실이지만 우리가 이상함을 느낄 포인트는 왜 바퀴 클래스가 두 가지 일을 하고 있냐!는 것이다.

자전거가 날고싶을때, 땅에서 앞으로 가고싶을때 두 경우 모두 바퀴 클래스의 메소드를 호출해야 하는것이다. 

만약에 바퀴 클래스의 fly 메소드가 굉장히 무겁다고 생각해보자. 

자전거가 roll 메소드를 호출할 때 마다 거대한 바퀴 클래스를 이용해야 하므로 자전거가 앞으로 나갈때 엄청나게 힘겹게 앞으로 나가야 할 수도 있다.


코드를 고쳐보자.


Class Wheel {

public :

void roll () {

...

}

}


Class Wing {

public :

void fly () {

...

}

};


해결 방법은 Extract Class (클래스로 빼내기) 즉, 그저 역할에 맞게 클래스를 나누어 메소드를 주면 된다. (이렇게 간단할 수가 없다.)


혹자는 "그럼 클래스가 너무 많아져서 오히려 복잡한거 아닌가?" 라고 의문을 가질수도 있겠다.

그러나 OOP의 첫번째 O 는 Object, 즉 객체다. OOP가 원래 객체를 많이 만드는 프로그래밍 방식이다.

그렇지만 자신의 판단하기에 클래스가 너무 많이 복잡한것 같다고 생각이 들면 알아서 합쳐라. 

설계에는 답이 없고 어디까지나 원칙이니 예외가 존재할것이다. (예외 상황인지 아닌지 판단하는건 경험이 많이 필요하다는것을 잊지말것!)