Encapsulation
객체 지향 설계법, 또는 객체 지향 프로그래밍1(OOP: Object Oriented Programming)은 이제 너무 흔한 말이 되었다. 객체지향방법을 적용하면 유지보수가 쉽기 때문에 소프트웨어의 품질이 올라간다는 이야기도 이제는 고전이 되었다. 하지만, 왜 유지보수가 편한지 쉽게 납득시켜주는 경우는 별로 없었다. 완전히 추상적이고 철학적이거나 아니면 '그냥 그런 것'이라고 단정짓는 경우가 대부분이었다. 많은 학생들의 사정도 비슷했을 것이다. 회사 과제를 하면서 만나게 된 많은 개발자들이 자바(Java)를 사용하고 있었으나, 그 사람들이 만든 결과물의 품질은 높지 않았다. 기능을 변경하는 것에 유연하지 못했으며, 기능변경에 대한 부작용이 너무 컸다. 검증 기간 중에는 자신이 만든 코드(Source Code)가 혹시 문제를 일으킬수도 있으니 트렁크 프리징(Trunk Freezing)을 해야 한다고 당당하게 말하는 사람도 있었다. 그 사람의 말에 따르면 모든 개발자들은 검증을 안전하게 통과할 때까지 자신의 작업물은 자신의 개발환경에 보관하고 있어야 한다고 했다. 객체지향은 유지보수에 좋고 자바는 가장 대표적인 객체지향언어지만 막상 현실에서는 경직되고 부작용이 많은 결과물들이 만들어지고 있었다. 이러한 현상의 원인이 개발자 각자의 경험 또는 공부 부족일 수도 있다. 하지만, 아주 사소한 기초를 놓쳐서 이러한 현상이 나타난 것일 수도 있다.
경험에 의하면, 개인적인 생각으로는, 객체 지향 방법에서 가장 중요한 것은 '간섭'이라고 생각한다. '상속'이 아니어서 의아한 사람들도 많이 있겠지만, 가장 중요한 것은 객체를 존중해 주는 것이라고 생각하기 때문이다. 객체를 존중한다는 말은 간섭을 하지말라는 뜻이며, 전문용어로는 은닉화(Encapsulation)라고 부른다. 간섭하지 않는 것이 중요한 이유를 우리는 회사 생활에서 쉽게 찾을 수 있다. 직장 상사가 어떤 일을 부탁했는데, 하나부터 열까지 깐깐하게 참견하고 속내용까지 들쑤셔 놓으면 오히려 일은 잘 되지 않고 시간은 더 걸린다. 오전에 참견한 내용과 오후에 참견한 내용이 달라지면 최악이다. 객체를 다루는 것도 비슷하다. 미주알고주알 그 속을 들여다 보면서 마구잡이로 상태를 흔들다보면 엉뚱한 결과가 튀어나온다. 게다가 왜 그런 결과가 나왔는 지 명확하게 진단하기도 어렵다. 우리의 회사생활도 비슷하다. 온갖 참견은 다 하다가도 정작 일이 잘 안되면 남탓을 하는 기회주의자들을 보게된다. 안타깝게도 뚜렷하게 그 사람의 잘못을 지적해 내기는 현실적으로 어렵다. 매우 이상적인 상황이겠지만, 반대의 경우를 생각해보자. 명확한 업무 목표와 일정을 전달해 주고 결과를 기다려 주는 동료를 만날 수도 있다. 간섭으로 인하여 피곤할 일도 없고 일하는 사람도 집중해서 일을 잘 마무리 할 수 있다. 업무 결과에 대한 평가도 보다 공정하고 객관적으로 할 수 있다. 객체를 다룰 때도 비슷하다. 이러한 명확한 업무 지시를 우리는 인터페이스(Interface)라고 부른다. 그래서 객체지향방법에서는 인터페이스가 정말 중요하다. 현실에서 똑부러지는직장 상사나 선배를 만나기는 쉽지않다. 마찬가지로 객체지향의 사상을 잘 따르고 실천하는 개발자를 만나는 것도 쉬운 일은 아니다. 하지만 매일매일 조금씩이라도 노력해서 간섭은 덜하고 믿음을 더해서 나 자신이 그렇게 좋은 선배 개발자가 되도록 노력하는 것이 좋겠다.
- 객체지향은 모든 정보를 객체들의 연관관계로 설명하는 기법이기 때문에 객체 기반 프로그래밍이 더 적절한 표현이라는 의견에 동의한다. [본문으로]