캡슐화란?

OOP에는 상속, 다형성, 캡슐화등 다양한 기법들이 존재한다.

그중 귀에 못미 박히도록 듣는 캡슐화에 대해서 알아보자.

 

캡슐화

객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고, 실제 구현 내용 일부를 외부에 감추어 은닉하는 걸 의미한다.

 

그렇다면 캡슐화는 왜 중요할까?

결론적으로 말하자면, 코드의 중복과 외부 변화에 대해 유연성과 확장성을 보장해주기 때문에 그렇다.

또한 객체에 직접 접근하는걸 방자함으로써, 예상치 못한 상황을 줄여준다.

 

하나의 예를 들어보자.

public class GoodStore {
    private int goodAmount;
}

public void purchaseGood() {
    GoodStore goodStore = new GoodStore();
    goodStore.goodAmount *= 0.9;
}

 

상품 스토어가 존재하고, 이 상품 스토어에 10%할인을 해준다고 가정하자. 

이 경우 2가지 문제점이 존재한다.

첫번째는, 상품할인과 관련된 메소드에서 전부 * 0.9를 선언해야 하며 이는 코드의 중복을 야기할수 있다는 것이다.

두번째는, 예외가 발생할수 있다는 점이다.

예를 들어, 할인률이 20%로 변한다고 했을 경우, 0.9라고 되있는 모든곳을 바꿔야 한다. 하지만 0.9가 아니라 -0.1을 이용하는 경우가 있을수도 있을 것이다. 즉 예측이 어렵다 라는 의미이다.

 

따라서, GoodStore 내부에 할인과 관련된 로직을 담아두는 것이다.

public class GoodStore {
    private int goodAmount;
    
    public int discount() {
        return (int) (this.goodAmount * 0.9);
    }
}

public void purchaseGood() {
    GoodStore goodStore = new GoodStore();
    int goodAmount = goodStore.discount();
}

위와 차이점을 살펴보면 캡슐화로 이어지는 객체 은닉성에 대해 좀더 자세히 알수 있다.

위의 경우 객체의 내부 메소드에 직접 접근하고 수정함으로써 행위에 대한 책임이 purchase Method가 지게 된다. 이는 객체지향의 Solid 원칙에 위배되는 것이고, 이럴 경우 객체와 메소드간에 강한 의존성과 결합성을 가지게 된다.

 

반면에, 밑의 경우는 할인에 대한 책임을 온전히 GoodStore에서 지게 된다. 그리고 purchaseGood은 단지 값을 가져다 사용하는 것뿐이다. 

이는 그냥 호출하여 사용하기 때문에 느슨한 결합을 유지하며, 확장과 변하에 유용하게 대처가 가능하다.