오늘은 메소드 접근자에 대해서 이야기해봅니다. 참, 저는 자바를 사용하기 때문에 메소드라는 단어를 쓰고 있지만 C++에 익숙한 사람은 함수로 이해하시면 됩니다.

클래스의 캡슐화를 위해서 메소드는 접근자를 설정할 수 있는데요,


아래로 갈수록 비공개적인 메소드가 됩니다.

프로그램을 처음 배우고나서 한동안은 public 이외의 접근자는 사용하지 않는게 정상입니다. 전 public 이외의 다른 것을 쓰기까지 1년이 넘게 걸린 것 같아요.

하지만 public 으로 공개된 API는 일단 공표된 이후 메소드의 원형 - 즉 인터페이스는 더 이상 (쉽게) 바꿀 수 없습니다. 에? 그냥 코드 수정하면 되는거 아니냐구요?

네, 안됩니다. 안된다고 생각하기까지 저는 1년이 걸렸습니다. 예를 들어볼게요. 혼자서 프로그램을 작성하지 않고 여러 사람이, 특히 전체 프로젝트가 계층 구조를 이루고 있는 경우를 생각해 봅시다. 그리고 자신의 팀이 상위 계층의 구현을 담당하고, 하위 계층은 상위 계층의 클래스를 상속받아서 또는 이용해서 구현한다고 생각해 보세요. package-private이나 private로 선언된 메소드는 외부에 공개되는 API가 아니기 때문에 개선 과정에서 얼마든지 수정이 가능합니다. 하지만 public은 어떨까요? 내부 구현이야 상관없지만 메소드 원형을 수정하면 그것을 이용하는 하위 계층의 모든 팀들이 다 같이 수정해야합니다. 만약 public으로 선언된 메소드를 필요없다고 없에버리면? 혹시나 그것을 이용한 팀은 또 한숨이 나오겠지요... 추가는 상관없을거라구요? 음... 신경 쓰이는건 비슷합니다. ^^;;

그래서 저는 클래스를 구현할 때 처음부터 private으로 놓고 시작합니다. 그리고 고민에 고민을 거듭해 package-private로 한단계 올리지요. 그리고 또 고민의 고민을 거듭해 protected와 public으로 단계를 올립니다. 가장 중요한 것은, public으로 선언되는 메소드들이지요.

서론이 무척 길죠? 에? 이게 본론 아니냐구요? *^^* 죄송합니다. 오늘 제가 이야기 하려는 것은... 이 이후의 이야기입니다. 하지만 짧은 내용이고 저도 어제부터 생각한 것이라... 여기서부터는 그냥 흘려 들으셔도 되요.

메소드를 public 으로 선언하는것에 이렇게 보수적이 되면 그만큼 안전하고 변경에 강한 것은 사실입니다. 인터페이스를 먼저 설계하라고 하잖아요? 괜히 나온 말이 아니라구요.. 하지만 너무 이렇게 소극적으로 설계하게되면, 자신이 설계하고 구현한 클래스가 현재의 프로젝트에 너무 강하게 묶여버립니다. 결국 그 프로젝트 이외의 곳에서는 사용하기 힘든 클래스가 됩니다. 그러다보니 다른 프로젝트에서 비슷한 기능을 구현하기 위해 Copy & Paste 를 자주 하게 되지요.

객체 지향의 장점 중 하나는 분명 재사용성에 있습니다.

따라서, public 메소드는 - 즉 인터페이스는 신중에 신중을 거듭하되 현재 진행중인 프로젝트에 너무 묶인체로 고민하지 않기를... 사실은 결국 그 자체가 또다시 인터페이스에 신중하라는 이야기가 되고 있지만, 이것은 경험상 분명히 미묘한 차이가 있기에 글로 적어봅니다.