캡슐화만 잘해도 좋은 코드를 만들 가능성을 높여준다.
캡슐화(Encapsulation)
캡슐화는 데이터와 그 데이터와 관련된 기능을 묶는 것이다.
캡슐화를 할 때 객체가 기능을 어떻게 구현했는지는 외부에 보여주지 않는다. 실제 구현에 사용된 데이터가 어떤 타입인지, 그 데이터의 값을 어떻게 사용하는지 외부에서는 알 수 없다.
예전에는 정보 은닉이라고 데이터를 감춘다고 해서 구분해서 사용되긴 했으나 최근에는 캡슐화속에 정보 은닉의 의미를 포함해서 표현하는 경우가 많다.
캡슐화는 왜 할까?
가장 큰 이유는 외부에 영향없이 객체 내부 구현을 변경할 수 있기 때문이다.
캡슐화를 하지 않으면 요구사항에 변화가 생겼을 때 데이터를 사용하는 방법에 변화가 생기면서 그 데이터를 사용하는 많은 코드에 수정이 발생하게 된다.
이게 절차지향(데이터를 공유하는 방식)의 단점이기도 하다.
캡슐화를 하지 않으면 데이터의 사용법이 변경됨으로 인해 변경해야 하는 코드가 연쇄적으로 발생한다.
캡슐화를 하면
캡슐화는 데이터와 관련된 기능을 하나로 묶는 것이고 그 관련 기능 구현 상세를 감추는 것이다.
캡슐화가 되어있다면 내부 구현만 바꾸면 된다. 사용하는 코드는 변경하지 않을 수 있다는 것이다.
캡슐화를 하는 가장 큰 이유
캡슐화를 잘 하면 어떤 요구사항이 변경되었을 때 연쇄적으로 변경이 전파되는 것을 최소화 할 수 있다.
캡슐화를 시도하면 기능에 대한 이해도도 높일 수 있다.
해당 코드를 캡슐화를 하기 위해서는 해당 코드를 이해하게 된다. 이해(의도 파악)를 해야만 캡슐화를 할 수 있기 때문이다.
캡슐화를 위한 규칙
하고싶다고 자동으로 캡슐화를 할 수 있는 것은 아니다.
캡슐화의 규칙 첫번째로는 Tell, Don't Ask
데이터를 달라 하지말고 해달라고 하자.
데이터를 가져와서 확인(판단)하지 말고 데이터를 가져오는 이유가 있을 텐데 데이터를 가지고 있는 애한테 해달라고 요청을 하도록 해야 한다.
Tell, Don't Ask를 하면 캡슐화를 하게 될 가능성이 높아진다.
캡슐화의 규칙 두번째는 Demeter's Law
- 메소드에서 생성한 객체의 메서드만 호출
- 파라미터로 받은 객체의 메서드만 호출
- 필드로 참조하고 있는 객체의 메서드만 호출
메소드를 연속해서 부르지 말아야 한다. (여러개 연계해서 호출X)
특정 메소드 하나만 호출하도록 변경해야 한다.
이 방식을 사용하면 캡슐화를 할 가능성이 높아진다.
캡슐화는 기능의 구현을 외부에 감춘다.
캡슐화를 통해 기능을 사용하는 코드에 영향을 주지 않고 (혹은 최소화) 내부 구현을 변경할 수 있는 유연함을 얻을 수 있다.
캡슐화를 잘 할수록 수정/변경하는 비용을 줄이는 효과를 얻을 수 있다.
참고 자료
객체 지향 프로그래밍 입문
