[OOP] 객체 지향 설계를 해야 하는 이유
내가 컴퓨터 공학을 전공으로 선택한 후, 처음으로 흥미를 느낀 영역은 객체 지향 프로그래밍 (OOP) 이었다. 심지어 휴학을 하고 한 학기 동안 객체지향만 공부한 적도 있었다. (그렇다고 잘하는 건 아니다 ㅜ_ㅜ) 요즘 회사에서 객체지향언어의 대표적인 언어인 자바를 많이 쓰고 있는데, 문득 이런 생각이 들었다.
"내가 만약 책임자 직급이 되면 소스코드를 개발하고 수정하는 것을 넘어 설계까지 해야하는 때가 오지 않을까?"
그래서 오늘부터라도 그 순간을 위해 조금씩이나마 객체지향 설계에 대해 공부를 하려고 한다.
오늘 포스팅하는 내용은 정말 객체지향에 대해 아주 미미한 나의 지식을 끄적인 것이니 가볍게 읽고 넘어가 주면 좋겠다.
객체지향 설계의 핵심
예전에 한 회사 면접에 가니 면접관님이 이렇게 질문을 하셨다.
"객체지향 언어에서 제일 중요한게 뭐라고 생각하십니까?"
나는 이렇게 답했다.
"코드에 의존성을 줄이고, 결합도를 낮추는 것이라고 생각 합니다."
여러분도 각자 생각하시는 객체지향의 정의가 있을 것이다. 내가 한 말도 맞고 여러분이 생각한 것도 맞을 거다. 왜냐면 객체지향언어란 한마디로 정의하기엔 굉장히 넓은 영역이니깐..!
내가 한 말도 굉장히 맞는 말이다. 의존성을 줄이고 결합도를 낮추기 위해서는 객체지향에서 굉장히 핵심적인 개념인 캡슐화를 잘 활용해줘야한다. 캡슐화를 잘 활용하면 객체의 자율성이 높아지고, 응집도가 높아져 객체지향을 더 완벽하게 구현할 수 있게 된다.
캡슐화 한 메서드를 호출하는 방식으로 (이런걸 인터페이스라고 한다 보통) 메서드를 작은 단위로 나누고, 코드를 자잘 자잘하게 나눠주면 객체지향에 한발짝 다가선 코드를 작성할 수 있다.
그런데, 객체지향을 코딩해보신 분들이라면 이런 경험을 한 적 있을 거다. 객체의 자율성을 높이다 보면, 또 다른 객체에서 의존이 발생하는 걸 경험해본 적 있을 거다. 처음 공부하시는 분들도 하다보면 깨달을 거다. 나중에 이런 경험 한번 하고나면 여기와서 댓글 하나 남겨주라.
이렇게 객체의 자율성은 상승하지만 결합도는 높아지는 모순이 발생하는데, 이런걸 전문 용어로 트레이드 오프가 발생했다고 한다. 내가 생각하기에 이걸 잘 조절하는 사람이야 말로 객체지향프로그래밍을 진짜 잘하는 사람이 아닐까 생각한다.
객체지향의 세계에서는 모든 객체가 자율적인 존재이다. 현실 세계와는 다르다.
현실 세계에서 여러분이 사용하는 연필은 자율 적인 존재인가? 지금 이글을 읽으면서 먹고 있는 라면은 자율적인 존재인가? 지금 여러분이 읽고 있지는 않지만 라면냄비를 올려 놓은 책은 자율적인 존재인가? 얘네들은 여러분이 사용하는 굉장히 수동적인 존재다.
객체지향의 세계는 다르다. 이 모든 것들이 능동적이고 자율적인 존재이다. 이런 객체지향 설계원칙을 바로 의인화(anthropomorphism) 이라고 한다.
의인화 뿐만아니라 객체지향 설계의 핵심적인 원칙 중에 책임의 이동 (shift of responsibility) 이라는 원칙이 있다. 책임은 객체의 기능이라고 생각하면 된다. 위에서 말했 듯 모든 객체는 자율적이라고 했다. 자율적인 존재에게는 책임이 존재한다.
훌륭한 객체지향 언어는 이 책임을 한 객체에게만 주지 않는다. 한 객체에게 책임을 다 지게하는 코드는 객체지향 설계를 지킨 코드가 아니다. 이러한 코드는 바로 절차지향 프로그래밍 방식으로 짠 코드이다. 이렇게 책임을 잘 나눠주면 객체는 자신을 스스로 책임지게 된다. 이러한 코드는 굉장히 이해가 쉬워진다.
객체 지향 설계의 중요성
객체지향을 철저하게 지키고 설계를 하면 요구하는 기능을 완벽하게 수행하면서도, 변경하기 쉬운 ( 다른 말로 이해하기 쉬운) 코드를 작성할 수 있다.
변경이 쉬운 코드가 왜 좋은 코드냐고? 여러분들 일할 때 보면 , 시시때때로 요구사항이 바뀌는 경험들 한번쯤은 해보셨을 거다. 특히 요즘에는 애자일 방식으로 프로젝트를 많이 진행하는데, 이렇게 개발하는 도중에도 요구 사항이 바뀔 수 있다는 말이다. 그렇게에 코드는 완벽하게 기능이 동작해야하고, 변경하기도 쉬워야한다.
쓰다 보니 글이 굉장히 길었다. 그럼 즐겁게 설계공부 시작해보자!