Frudy
4k
2019-11-24 22:02:03 작성 2019-11-24 22:13:11 수정됨
14
1062

제가 캡슐화를 좋아하는 이유. (예시 : Java, Javascript)


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를 공부하고있습니다.

1
1
  • 댓글 14

  • 굴림체
    257
    2019-11-25 00:38:24

    다양한 고민을 하는건 좋으나.. 이미 검증된 동일한 패턴이 있음에도 불구하고 

    자신만에 패턴을 만들어 사용하는것은 좋지 않다 봅니다.

    비공개 맴버함수 공개 메서드 패턴은 여러가지로 자바스크립트에 존재합니다.


    1
  • Frudy
    4k
    2019-11-25 01:32:22
    조언감사합니다~~
    0
  • NPE
    595
    2019-11-25 05:19:56 작성 2019-11-25 13:10:02 수정됨
    "카더라"보다 디자인 패턴 책을 읽으시면 좋을 것 같네요.
    캡슐화는 api를 사용하는 "클라이언트" 입장에서 생각하면 됩니다.
    클라이언트가 커피머신을 이용한다고 가정할 때,
    "코드 꼽고, 물 넣고, 원두 채우고, ... , 만약 커피 찌꺼기가 있으면 비우고, ..., 아메리카노 내리는 버튼 누르기" 보다 그냥 "아메리카노 한잔 내려" 라고 하는 게 원래 의도겠죠.
    2
  • pooq
    3k
    2019-11-25 07:40:56

    캡슐화를 하다보면 계속해서 막히는 문제가 생기는데, 이런 불편한 문제를 효율적으로 해결한게 디자인 패턴이죠.

    0
  • __jj__
    224
    2019-11-25 08:57:36

    디자인 패턴 책 강추합니다.

     이정도로 객체지향에 대한 이해과 응용을 하신다면 이제 패턴화된 부분을 이해하고 적용하시면 현장에서 훨씬 빠르고, 안정된 개발에 도움이 될 거예요.

    전역번수 사용의 남발은 정말... 지양해야 할 일입니다.

    0
  • ilovepc
    55
    2019-11-25 09:32:52

    좋은 글 감사합니다

    0
  • Frudy
    4k
    2019-11-25 12:58:10

    ㅎㅎㅎ 개빌재밌네요

    조언감사합니다!

    0
  • Frudy
    4k
    2019-11-25 13:00:56

    오....

    캡슐화를 그렇게도 해석할수있군여

    저는그냥 한번에 여러개 고려하기싫어서

    그랬는데... 감사합니다~~

    0
  • NPE
    595
    2019-11-25 13:12:13 작성 2019-11-25 13:20:59 수정됨

    Frudy

    그렇게도 해석할 수 있는게 아니라 캡슐화의 정의의 한 예입니다. (위 예시는 Facade 패턴)

    "API는 노출하되, 내부 구현은 감춘다."


    덧붙임) 굴림체 님께서 먼저 말씀하셨지만, 개발자간의 공통된 지식을 무시하고 자신만의 방향으로 공부하시면 나중에 협업시 개발자간의 소통에 문제가 생길 수 있습니다.

    0
  • meaway
    220
    2019-11-25 14:04:42

    closer => closure?


    클로저는 js 기본 동작원리 중 하나인데 프레임워크를 이런 것보다 우선순위에 두시는 이유가 따로 있으신가요?


    0
  • Frudy
    4k
    2019-11-25 20:00:20 작성 2019-11-25 20:03:35 수정됨
    클로저는 아직 실무에서 응용을 못했어요.
    그런데 당장 이직할 회사는 뷰를 쓴대요.
    그래서 우선순위는 뷰가 높아요.

    자바스크립트만 계속 공부할수는 없겠더라구요.

    엇 클로저 영어로 잘못알고있었군요;

    그리고 조언 감사합니다.
    0
  • Frudy
    4k
    2019-11-25 20:02:27

    음 그리고 제가 캡슐화를 이상하게 알고있었군요


    제가 알고있는 저 개념은 뭘까요;

    저는저게 캡슐화라고 생각했는데.....

    0
  • meaway
    220
    2019-11-25 20:07:28

    ㅇㅎ 이직성공하셨군요

    축하드립니다 ㅎㅎ

    실무에서 뷰 쓰시는거면 프레임워크 당장 익숙해지셔야겟네요 ㅠㅠ

    0
  • Frudy
    4k
    2019-11-25 20:10:09 작성 2019-11-25 20:12:16 수정됨

    ㅎㅎㅎ 제가 이해하는 클로저에 대해

    시간나면 적어볼게요.


    Inner function 안에서

    상위 Scope에 있는 변수에 접근하는거보고

    정말 신기했는데


    클로저같은 기술(?)은 js에서 첨봐서

    처음에 더 신기했었어요.


    그나저나 캡슐화를 이상하게 알고있었는데

    운좋게 고칠수있는 기회가되어 다행입니다.


    이직해서 배울게 정말 많을거같아요.

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.