이 글을 쓰게 된 계기
각 학교의 컴퓨터 공학 커리큘럼에는 객체지향프로그래밍이라는 수업익 개설되어 있다. 나도 수업에서 상속 , 다형성, 동적바인딩과 같은 개념을 배웠지만 도대체 왜 객체지향프로그래밍이 필요한지를 이해한다기보다는 당연하게 "이런식으로 프로그래밍하면 편하겠구만" 생각했다.
하지만 요즘 토비의 스프링을 공부해나가면서 객지프를 나처럼 단순 하게 생각하면 안되고 프로그래밍은 만들떄는 반드시 객체지향의 설계원칙을 준수하도록 프로그래밍을 하는 건 선택이 아니라 필수이고 그러기위해 엄청난 노력을 해야한다는 것을 깨달았다.
나는 스프링을 공부해가면서 이런 객지프의 위대함과 객체지향의 설계원칙 을 기록으로 남겨보려고 한다.
객체지향프로그래밍의 시작
프로그램을 설계할 때,에러가 안나도록 작성하는것은 기본 + 에러(변화)가 발생해도 잘 대응을 할 수 있는 프로그램을 작성하기 위한 도구가 객지프다.
프로그램의 확장성
프로그램을 설계할때 가장 중요하게 고려해야할 부분은 내가 만드는 프로그램이 추후에 어떤 기능을 추가하고 변화할 것인지를 예측하는 것이다. 추후에 생길 변화를 미리예측하고 그 변화에 대해 적절한 대응을 할 수 있는 코드를 작성하는것은 매우 중요하다. 큰 그림을 잘 그려야한다는말
하지만 변화란 꼭 기능의 추가뿐 아니라 다양한 예외상황에서 발생할 가능성이 있다. 갑자기 서버가 다운된다거나 해당 우리 프로그램에서 이용하는 여러서비스 API들중 하나가 에러가 뜨거나 하는 상황말이다. 만약 우리의 프로그램이 커지면 커질수록 예외상황은 많이 발생할 확률은 필연적으로 커지고 이런 예외상황을 맞닥뜨리는건 어쩔 수 없다. 단지 이를 더 빠르고 직관적으로 대응할 수 있도록 하기 위해 우리는 객체지향적으로 프로그래밍 하는 것이다.
단일 책임의 원칙
가장 기본은 하나의 모듈(오브젝트)은 각각 자기의 몫의 책임을 맡아 하는 구조로 만든다.
만약, 사용자 정보의 디비접근을 담당하는 UserDao오브젝트가 있다고 하자. 이 UserDao클래스는 프로그램이 사용할 DB커넥션을 만들고 연결하여 해당 디비로 CRUD메소드를 실행한다.
그럼 UserDao는 디비 연결과 데이터엑세스 두기능을 담고 있다. 이때, 만약 우리가 사용하던 디비가 다운되어 다른 디비로 교체하기 위해서는 어디를 수정해야할까?
UserDao에서 우리가 사용하려던 디비로 커넥션을 다시생성하고 연결하는 코드를 다시 작성해야 한다. 좀 이상하지 않은가?
보통 Dao클래스는 데이터를 어떻게 가져오고 등록할 것인지 데이터엑세스 기능을 담게 되는데 이렇게 두개의 기능을 담게 되면 코드를 해야하는 이유도 두개가 된다. 따라서 이러한 하나의 모듈에 여러개의 기능을 담게 되면 결국 나중에 가서 코드의 어느 부분을 수정해야 할지 찾는데 시간이 오래걸릴뿐 아니라 한번 수정하면 될 작업을 여러번 수정해야 하는 번거로움을 수고해야하고 이로써 예외상황은 더 많이 생길 가능성이 높아진다.
디비서버가 다운되든 디비가 교체되든 디비와 관련된 변경사항이 생기는 어떠한 상황속에서도 UserDao는 어떤 코드도 수정되면 안되도록 해야한다.
단일 책임원칙
하나의 모듈은 한가지 책임을 가지도록 하여 하나의 모듈이 바뀌는 이유는 한 가지이도록 만든다.
즉, 단일 책임 원칙을 통해 우리는 변경에 대한 수정대상이 명확해진다는 이점을 얻는다.
많은 코드를 수정하는 작업에선 그만큼 실수가 일어날 확률이 높다.
따라서 적절하게 책임과 관심이 다른 코드를 분리하고 서로 영향을 주지 않도록 인터페이스와 같은 다양한 추상화 기법을 도입하고 애플리케이션 로직과 기술환경을 분리하는 등의 작업은 복잡한 애플리케이션에 반드시 필요하다.
이로써 단일책임 원칙 뿐 아니라 모듈간에 결합도가 낮아서 서로의 변경이 영향을 주지않고 같은 이유로 변경이 단일 책임에 집중되는 응집도 높은 코드가 나온다.
이론적으로는 위와 같긴 하지만, 실제로 높은 응집도와 낮은 결합도를 만족하는 설계는 구현하기가 쉽지않다. 많은 경험과 다양한 경우를 고려하여 적절한 타협점을 찾아야 한다.
