[OOP] 캡슐화

최근 인프런 : 객체지향 프로그래밍 강의를 보며 객체지향에 대해 지식을 다시 한번 점검하고 쌓고 있다. 

 

모든 내용이 중요하지만 그래도, 꼭 내기준에서 남겨놔야 할 것 같은 내용들에 대해 재 정리를 하며 기록하고자 한다.

 

캡슐 캡슐

캡슐화 ( Encapsulation ) 

• 데이터 + 관련 기능 묶기 
•  객체가 기능을 어떻게 구현했는지 외부에 감추기 
  • 구현에 사용된 데이터의 상세 내용을 외부에 감추는 것
• 정보은닉 ( Information Hiding) 의미 포함 
  • 데이터를 외부에 감추는것을 의미 
  • 정보은닉과 캡슐화를 구분 지어 표현하였지만, 최근 캡슐화에 정보은닉을 포함하여 표현한다.
• 왜쓸까? 
  • 외부의 영향 없이 객체 내부 구현 변경이 가능하기 때문 

 

캡슐화를 하지 않는다면 어떻게 될까? 

캡슐화를 하지 않았을때의 경우

다음은 요구사항의 변경으로서, Account의 로직을 변경해야 하는 경우가 생겼을 때 

 

각 영향을 받는 코드들의 수정이 발생하게 되어진다. 

 

이는 절차지향의 단점으로도 볼 수 있다.

 

 

캡슐화는 연쇄적인 변경 전파를 최소화시킨다. 

 

캡슐화를 진행시

만약 캡슐화를 진행한 상황에서, 해당 내부 구현을 변경해야 하는 경우가 생길 시

 

변화가 요구되는 해당 코드의 내부 로직만 변경함으로서 이전보다 더 간편하게 변경이 가능하다. 

 

즉, 각 코드별 결합도가 더 느슨해짐으로서 각 코드 간의 의존도를 떨어뜨리는 게 핵심이지 않을까란 생각이 들었다. 

 

Tell, Don't Ask 

데이터를 해달라 하지 말고 해달라고 이야기 하기

 

즉, 비지니스 로직 내 객체의 데이터를 제공한 상태로 처리를 요구하는 것이 아닌, 해당 객체가 판단하여 결과를 요구하도록 하는 규칙 

 

적용 전, 코드

구현이 아닌 연습이기에 빨간 줄은 양해 바랍니다..  

 

해당 서비스 클래스 내, Member에 대한 결과 값에 대한 비교가 있다 가정 시, 다음 코드의 WorkFlow는 

 

Member 안의 VerificationEmailStatus 의 값을 꺼낸 후, 서비스 클래스 내 2와 비교 후 해당 값이 true 일시 다음 값을 return 하는 결과이다. 

 

하지만, 위 if 비교는 Member 객체 안 의 데이터의 비교 즉, Member 객체 안에서의 처리가 가능하다. 한번 적용해보자 

적용 후 - 빨간줄은 양해 부탁드립니다 ㅠ

 

Member 객체 안

다음과 같이 Member 객체 안에서 비교를 두고 해당 객체의 결과 값만을 서비스 클래스에서는 알게 된다. 

 

만약, 요구사항 변경으로 값을 수정해야하는 상황이 올 시 서비스 클래스가 아닌 객체 내에서 변경하면 된다.

 

내가 느낀바로 이에 핵심은  "값을 꺼내서 보여주고 결과를 요구하는 것이 아닌 결과만을 제공하는 것"이라 생각했다. 

 

각 기능 구현을 외부에 감추고 결과 값만을 제공하기에, 비즈니스 로직에 영향을 최소화하거나 주지 않고, 요구사항에 변화가 요구되는 기능만을 수정할 수 있는 유연한 코드를 작성할 수 있는 게 핵심 포인트이다.