 |
실전 코드로 배우는 실용주의 디자인 패턴 -  앨런 홀럽 지음, 송치형 옮김/사이텍미디어(희중당) |
요즘 출퇴근시에 이 책을 읽으면서 많은 것을 깨닫고 있습니다. 지금까지 제가 한 코딩 방식은 객체 지향이 아니었습니다. 으헉!! 초반부에 Get과 Set의 접근/수정 메소드에 대한 이야기가 나오더군요. 요근래 다른 개발자 분들의 블로그에서도 관련 이슈를 보긴 봤는데 ( Get/Set을 쓰지말자는 ) 그다지 수긍이 가지 않았습니다. 그렇게까지 해야 하나? 라는 기분이었죠. 하지만 위 책에서의 내용을 보자니 오호~ 라는 감탄사가 나오더군요. 내용이 굉장히 설득력 있고 타당한 이유와 예시를 제시해주는데 확 와닿더군요. ( 덕분에 제 프로젝트도 리팩토링 들어갔습니다 )
책에서 나오는 Get/Set에 대한 정리를 나열해보자면...
객체는 내부 데이터와 구현을 노출시키면 안된다. 접근 메소드와 수정 메소드는 내부 데이터와 구현을 노출시키므로 유지 보수에 악영향을 미치며, 가능한 사용하지 말아야 한다.
필드를 Private로 만들고, Public Get/Set 메소드를 추가하는 것은 코드를 복잡하게 만들 뿐 대게 아무런 이득도 없다.
객체들 간의 관계를 세심히 디자인 하였다면 대부분의 클래스는 Get/Set 메소드를 필요로 하지 않는다.
구현 은닉이 제대로 되어 있는가? 즉, 클래스의 구현 방식을 마음대로 바꾸어도 외부에 영향을 미치지 않는가?
어떤 작업을 수행하는데 필요한 정보를 요구하지 말라. 대신 정보를 갖고 있는 객체에 일을 해달라고 부탁하라.
즉, 이런식으로 코딩을 하라는 겁니다.
// 잘못된 예 // get과 set으로 내부 데이터 노출 Money a, b, c; a.setvalue( b.getvalue() + c.getvalue() ); // 잘된 예 // Money 객체에 일을 해달라고 요청하라. Money a, b; a.increaseBy( b );
극단적인 예로 int형을 반환하는 get 메소드를 호출 하는 곳이 1,000 곳이 있는데, 프로그램 수정으로 인해 반환 타입을 long으로 바꾸게 되면 get 메소드를 호출 하는 1,000곳을 모두 수정해야 하는 사태가 발생되죠. 하지만, get을 쓰지 않고 해당 객체에 일을 해달라고 요청하는 형태로 메소드를 수정 하면, 반환 타입이 바뀌더라도 클래스 내부만 수정하면 되니 유지보수가 훨씬 수월해지는 것 입니다.
말로 표현 하자면 "이 속성 값을 줘. 그래야 내가 그 것을 출력할 수 있어" 라고 하지 말고, "이 속성을 출력해줘" 라고 하는 거죠.
처음 C++을 배우며 객체 지향에 대해 공부할때 데이터 은닉에 대해 보긴 봤지만 이렇게까지 의식하면서 코딩을 하지않았죠. 정말 아무런 생각없이 Get/Set을 써왔는데, 이제는 다르게 써봐야겠습니다.