결론적으로 상태를 잘 정의된 행동 집합 뒤로 캡슐화하는 것은 객체의 자율성을 높이고 협력을 단순하고 유연하게 만든다. 이것이 상태를 캡슐화해야 하는 이유다.
'객체지향의 사실과 오해'에 다음과 같은 구절이 있었다. 뭔소린지 크게 와닿지 않는다..
객체지향 프로그래밍을 하고 있음에도 그 이점이 무엇인지 깊게 파고들어 본 적이 없다. 더군다나 학부생때부터 지겹도록 들었던 '캡슐화'.. 캡슐화가 이점인건 알겠는데 뭐가 이점인건데?
1. 캡슐화를 하면 코드의 중복을 막을 수 있다.
한 클래스의 속성을 직접 꺼내와서 계산하게 한다면, 다른 여러 도메인 객체에서 해당 동작이 필요할 경우 코드를 중복적으로 작성할 수 밖에 없다.
-> 코드의 중복은 변경에 취약하다.
도메인 요구사항이 변경 됐다고 치면 중복된 코드들을 일일히 찾아가서 수정해줘야 한다.
2. 캡슐화는 객체에 대해서 알아야하는 지식의 양을 줄여준다.
자동차 객체를 움직이려고 한다. 캡슐화가 잘 되어있는 경우에 우리는 move() 메서드만 호출해도 될 것이다. 그렇지 않다면 자동차 객체가 어떤 속성을 가지고 있는지 알아야하고 직접 조작해줘야한다. 다른 객체에서 자동차 객체의 속성을 굳이 알 필요가 없다.
3. 캡슐화를 하면 외부에서 조작하여 속성을 변경하는 일을 막을 수 있다.
캡슐화가 제대로 되어있지 않다면 클래스 외부에서 속성을 마음대로 조작할 수 있다. 변경에 민감한 정보가 저장되어있다면 이런 일은 일어나지 않아야 한다.
객체의 자율성을 높인다는 것은 곧 다른 협력하는 객체가 알아야하는 정보의 양을 줄일 수 있다는 것이 아닐까 싶다. 협력을 단순하고 유연하게 만든다는 것도 협력을 함으로써 코드의 중복을 줄일 수 있고 변경에 유연하게 대처 가능하다는 뜻이 아닐까 하는 나만의 해석을 해본다.
마루의 캡슐화 정리는 귀하군요.. 정리 잘 해두셨네요👍 잘 읽고 갑니다!