4.5개월차 신입 입장에서 생각하는 Encapsulation에 대해 적어볼게요.

부족한부분 지적해주시는 분들 항상 감사합니다.

1. 캡슐화란?

2. 제가 캡슐화를 좋아하는 (= 구현하는) 이유

3. 구현예시

ㅡㅡㅡㅡ

정의를 보면 다.. 은닉한다는 말이 있어요.

실제 구현 내용 일부를 외부에 감추어 은닉한다.

(출처 :위키백과)

그래서 무슨말인지 잘 모른채 거의 2년가까이 살았네요.

요즘 느끼는 제 생각은 이렇습니다.

>> 범위를 최대한 좁힌다.

1. 변수에 다른값을 할당할 수 있는 범위도 최대한 좁히고,

2. 변수의 값을 읽을 수 있는 범위도 최대한 좁히고,

3. 메소드나 함수를 호출할 수 있는 범위도 최대한 좁히는거라고 생각해요.

최대한 좁혀서 외부에서는 호출할수도 읽을수도 다른값을 할당할수도 없으니

은닉한다 라고 표현을 하는거같아요 (추측)

private 키워드로 이렇게요.

ㅡㅡㅡㅡㅡ

제가 캡슐화를 사용하는 이유는,

생각해야하는 범위를 좁히고싶어서 에요.

저희회사 레거시 소스코드를 간단하게 보면 저렇게되어있어요.

전역변수로 선언되어있는 변수가 정말 많고 (예시에는 3개밖에..)

모든곳에서 호출할 수 있는 함수가 정말 많아요.

어디서도 호출할 수 있다.

==>

저 함수를 수정할 일이 생기면... (추가개발 or 버그수정)

(1) 현재 호출하고있는 곳을 모두 살펴봐야 수정해도 되는지 알 수 있고.. 

+ 어디서도 호출될 수 있기 때문에 호출되는 곳 살펴보는 것만으로도 시간이 오래걸립니다.

(2) 어디서도 호출할 수 있다 == 앞으로도 누군가 개발하면서 호출할 수 있기 때문에..

그 함수 제작하신분 의도에 맞지않는 호출을 할지도 모르기 때문에 버그가 발생할지도 몰라요.

실제로.. 저희 회사에서 정말 자주들었던 이야기인대요,

OO님 이런버그가 있어서 이거 이렇게 고쳐도 되나요?

==>

어...그거 바꾸면 밑에 다른데서 다 에러날지도 모르기 때문에 잘 바꿔야해요.

라는말을 자주들었어요.

물론 이것은 전역변수에도 동일하게 적용되요.

많은 전역함수(?)에서 전역변수 값을 계속 바꾸고있는 소스코드는,

실행순서를 따라가는것 조차도 힘들어요.

이걸 캡슐화로 구현하면 어떤 장점이 있냐면요,

생각할 수 있는 범위를 좁힐 수 있게되요.

암묵적으로 저 변수는 저 함수 안에서만 read되고 write 될 수 있기 때문에,

전역변수로 선언해서 쓰는것보다 생각하는 범위가 확 줄어들게되요.

그리고, 저희 레거시 소스코드 전역변수로 선언해놓은 애들 가만들여다보면,

쓰이는 함수는 몇개 없어요.

그렇다면 그 쓰이는 함수 안에서만 접근할 수 있도록 바꿔보면

읽는사람도 고치는사람도 추가개발하는사람도 모두에게 좋을거같아요.

스터디와 실무의 큰 차이점은,

개발하는 사람이 바뀔 수 있다는거라고 생각해요.

전역변수에 전역함수 선언하더라도, 처음 만든사람이 쭉 맡으면 큰문제가 안될지도 몰라요.

하지만 생각보다 아닌경우가 많아요.

(1) 제작자가 퇴사하여 뒷사람이 맡는 경우

(2) 제작자가 다른일을 맡아야되서 다른사람이 맡게되는 경우

(기타등등)

그래서.. 저는 생각해요.

(1) 호출할 수 있는 범위를 최대한 좁히고 (= 다른데서 호출못하게)

(2) 변수에 read하거나 write할 수 있는 범위를 최대한 좁혀서 (= 다른데서 수정못하고 읽지못하게)

뭐하나 고치거나 추가할 때 빠르게 판단할 수 있도록 하고있어요.

고민해야하는 범위가 줄어드니, 그만큼 더 좋아요.

객체지향의 핵심은,

시스템을 객체로 작게 쪼개서 구현하겠다는 패러다임이니까..

객체지향과 캡슐화는 정말 궁합이 잘맞는거같아요.

ㅡㅡㅡㅡㅡㅡ

Java는 Modifier Access라는 훌륭한 키워드가 있지만,

ES6 (Javascript)는 없더라구요.

그래서 책을 읽어보니

(1) inner function

(2) closer

Javascript는 이 2개로 캡슐화를 구현할 수 있다고 했으나,

closer는 제가 응용을 못해본 관계로 inner function만 예시로 들어볼게요.

Javascript는 inner function이란게 있는데,

내부함수는 일반적으로 외부함수 안에서만 호출할 수 있어요.

= 바깥에서 호출할 수 없어요.

= 암묵적으로 이 내부함수는 이 외부함수 안에서만 쓰려고 만든 함수라는걸 알려줄 수 있어요.

(1) 저렇게 전역변수에 저 내부함수를 저장하거나,

(2) 저 내부함수를 return하지 않는이상,

저 내부함수는 절대로 외부에서 호출할 수 없어요.

그래서,

처음에는 이 패턴을 사용했다가,

(저 이후로는 아무 실행문이 없고, 함수 선언문만 있음을 알려주기위해 주석을 달았었어요)

현재는 이 패턴을 쓰고있어요.

주석을 안달아도 직관적으로 제 의도를 전달할 수 있더라구요.

+

함수를 선언하기 전에 호출할 수 있는 이유는 Javascript의 호이스팅이라는 문법 때문이고,

더글라스 크락포드라는 선생님은 호이스팅 쓰지않는걸 권장하셨지만,

저는 현재 개인적인 이유로 딱 저 패턴에서는 호이스팅을 사용하고있어요.

이건 글 주제와 관련없으니 이정도만..

실제 예시는,

이거에요. (보안문제 없는 소스코드이니 공개할게요)

이런 창 컨트롤하는 함수인대,

가격/수량/금액/수수료 등등이 있어요.

그래서,

(1) 사용자가 입력한 값을 검증하는 내부함수1

(2) 검증된 값을 저기에 반영하는 내부함수2

이 2개는 외부에서 호출될 필요가 전혀 없어요.

(1) 다른 코인 시세창에서 주문창에 입력된 데이터 검증할 일 없고,

(2) 다른 코인 정보창에서 주문창에 입력값 반영할 일 없고..

(3) 마이페이지같은 다른페이지는 주문창하고 전-혀 관련없어요.

그런대도 외부에서 호출할 수 있도록 전역함수로 선언해야할 이유는 하나도없는거같아요.

ㅡㅡㅡㅡ

캡슐화를 구현해야는 이유는 조금 알고있는거같은데~

아직 구현실력은 미숙한 신입이 입니다.

디자인적으로 고민이 많았는데, 다행히 프레임워크가 이걸 많이 해결해준다고 해서..

현재는 closer가 아니라, react를 공부하고있습니다.