객체지향개념 캡슐화(Encapsulation)

캡슐화

 

이번엔 4대 객체지향개념 캡슐화에 대해 알아보려고 합니다.

"정보은닉" 여기까지 오신분들이라면 정보은닉이란 얘기는 셀수없이 보셨을거라 생각합니다.

그래서 도대체 왜 정보은닉을 해야하는걸까요?

 

 

• 캡슐화(encapsulation)
  • 속성(data fields)과 행위(methods)를 하나로 묶는다.
  • 구현 내용 일부를 외부에 감추어 은닉한다.

 

우선 아래의 코드를 한번 보겠습니다.

public class CalculationModel {
    int a;
    int b;
}

위와같은 데이터 모델이 있다고 가정합시다.

public class Math {

    CalculationModel dataModel = new CalculationModel();

    public Math(int a, int b) {
        CalculationModel.a = a;
        CalculationModel.b = b;
    }

    public int math() {
        int sum = CalculationModel.a + CalculationModel.b;  //요구사항 1
        int division = CalculationModel.a / CalculationModel.b; //요구사항 2
        return sum + division; //요구사항 3
    }
}

그리고 Math 클래스에서 CalculationModel 의 정보들을 그대로 사용하고 있습니다. 

CalculationModel 의 정보 은닉도 실패 했을 뿐더러 Math 과 CalculationModel 객체의 결합이 생겨버렸네요.

 

객체간의 결합은 생각하지 않고 여기선 캡슐화를 하지 않았을때의 문제만 생각해 봅시다.

어떤 상황에서든 요구조건은 변경되기 마련이며 확장성도 매우 중요합니다.

위의 코드에서 math() 메소드를 확인해봅시다.

- 요구사항

1. a + b

2. a / b

3. 요구사항 1 + 요구사항 2

 

기획자 : 저.. 기존 1번 요구사항 이였던 a + b 에 c 도 같이 더해주세요!

public class Math {

    CalculationModel calculationModel = new CalculationModel();

    public Math(int a, int b, int c) {
        calculationModel.a = a;
        calculationModel.b = b;
        calculationModel.c = c;
    }

    public int math() {
        int sum = calculationModel.a + calculationModel.b + calculationModel.c; <-요구사항 변경으로 인한 c 추가
        int division = calculationModel.a / calculationModel.b;
        return sum + division;
    }
}

앞으로 어떤 요구사항이 생길때마다 Math 클래스 에서 계속해서 수정을 해주어야 합니다. CalculationModel 객체를 

Math 클래스 뿐만이 아닌 여기 저기서 사용한다면 유지 보수 측면에서도 매우 좋지 않겠군요.

 

 

이제 캡슐화를 진행 해 봅시다.

public class Math {

    CalculationModel dataModel;

    public Math(int a, int b, int c) {
        dataModel = new CalculationModel(a,b,c);
    }

    public int math() {
        return dataModel.math();
    }
}

public class CalculationModel {

    private int a;
    private int b;
    private int c;

    public CalculationModel(int a, int b, int c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }

    public int plus() {
        return a+b+c;
    }

    public int division() {
        return a/b;
    }

    public int math() {
        return plus() + division();
    }
}

CalculationModel 의 각 변수(a,b,c)에 접근제어자 private 을 선언 해 줌으로써 이제 외부에서 직접적인 접근은 불가능하게 되었으며 필요한 메소드만 호출할 수 있게 되었습니다.

결국 위와 같다면 기획의 변경에따른 CalculationModel이 수정되니까 똑같은거 아니야? 라고 생각할 수 있습니다.

하지만 캡슐화는 정보의 은닉에 목적이 있습니다. 보통 만들어진 객체들은 1:1 관계인 경우도 있겠지만 1:n 의 관계가 될 수 있으며 많은곳에서 가져다 사용할 가능성이 있습니다. 만약 개발자가 다르다면 서로 다른 목적을 가지고 내부의 정보를 사용하게 될 위험이 있습니다.

위의 코드에서 Math 클래스와 CalculationModel 객체간의 결합도 interface를 사용하여 끊어내야 합니다.

사실 위와같은 예제는 억지스러운 예제입니다. 단순 설명을 위한 것 입니다. 

 

 

개발을 하게된다면 나 뿐이 아닌 다른 개발자들의 입장에서도 고려할 필요가 있습니다.

직관적인 메소드명은 매우 중요하다 생각합니다.

누군가 내가 만들어놓은 객체를 사용해야 한다면 변수의 사용의도 부터 알고리즘 등 모든걸 알기 원치 않을 수 있다는 것을 기억합시다.

 

캡슐화에 대해 설명해보았습니다.

캡슐화는 객체간의 결합도를 줄여주는 의존성주입, 팩토리패턴 등 각종 디자인 패턴의 기초가되는 개념이라 생각합니다.

아직 제가 부족해 더 많은 내용을 풀어내고 싶었지만 부족하여 더 알게되는 내용은 수정하는식으로 진행하겠습니다.

틀린점은 지적 부탁드리며 읽어주셔서 감사합니다.