ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [프로그래머] 상태뿐만 아니라 '동작'도 캡슐화 하라
    97가지 시리즈/프로그래머 2018.11.02 16:42

    #프로그래머가_알아야_할_97가지 vol.31

    상태뿐만 아니라 '동작'도 캡슐화 하라 by. Einar Landre


    시스템 이론(Systems Theory)에서 복잡한 구조의 대규모 시스템을 다룰 때 가장 중요한 것이 봉쇄(Containment)입니다. 소프트웨어 개발에 종사하는 사람이라면 봉쇄 혹은 캡슐화가 얼마나 중요한지는 충분히 이해하고 있을 것입니다. 프로그래밍 언어 역시 봉쇄를 고려한 구조로 되어 있습니다. 서브루틴과 함수, 모듈, 패키지, 클래스와 같은 요소들을 조합해 코드를 쓸 수 있게 되어 있는 것도 그 때문입니다.


    모듈과 패키지는 대규모 캡슐화로 서브루틴과 함수 클래스는 보다 섬세한 캡슐화로 처리합니다. 오랜 경험을 통해 알게 된 거지만, 이 요소 중에서도 개발자들이 가장 어려워하는 것이 클래스입니다. main메소드만 3,000줄이 넘는 클래스를 만들거나, 프리미티브형의 setter와 getter만 들어있는 클래스를 종종 보곤 합니다. 그런 코드를 보면 그 코드를 쓴 개발자가 객체 지향에 대해 충분히 이해하지 못했다는 걸 금방 알 수 있습니다. 객체의 모델로서의 측면이 전혀 활용되지 않았기 때문입니다. 평소 POJO (Plain Old Java Object), POCO (Plain Old C# Object 또는 Plain Old CLR Object)라는 단어에 익숙한 개발자에게 이 말은 객체 지향은 모델링 패러다임이고 그 원점으로 돌아가야 한다는 의미의 말입니다. 객체는 어디까지나 심플해야 하지만 심플함아무 생각이 없는 건 구별되어야 합니다.


    객체는 상태동작을 모두 캡슐화 할 수 있습니다. 또한, 어떤 동작이 될지는 그때그때의 상태에 따라 달라집니다. '문'이라는 객체를 예로 들어 보겠습니다. 문에는 [닫혀 있음], [열려 있음], [닫히는 중], [열리는 중]과 같이 네 종류의 상태가 있습니다. 그리고 문의 조작에는, "열다"와 "닫다" 두 종류가 있습니다. 같은 "닫다"여도, 열려 있을 때의 "닫다"와 열리는 중에 "닫다"의 동작은 달라집니다. 그때그때 문의 상태에 따라 동작이 달라진다는 뜻입니다. 이처럼 각각의 객체가 원래 어떠한 특성이 있는지를 잘 검토하면, 설계는 이론적으로는 그다지 어렵지 않을 것입니다. 사실 해야 할 일은 두 가지 밖에 없습니다. 하나는 객체에 임무를 할당하고 다른 하나는 다른 객체에 임무를 위임하는 겁니다. 여기에는 객체 간의 상호작용에 대한 프로토콜과 관련되어 있습니다.


    이해하기 쉽도록, 예를 들어 봅시다. Customer, Order, Item이라는 세 가지 객체가 있습니다. Customer 객체는 신용 한도와 신용 조사 규칙을 유지하는 것이 자연스러울 것입니다. Order 객체는 관련된 Customer 객체를 알고 있고, Order 객체의 addltem 메소드는 customer.validateCredit(item.price()) 를 호출해서 신용조사를 위임합니다. 메소드가 실행되어 신용 조사가 실패했을 때는, 예외가 던져져 구매 처리는 중단 됩니다.


    객체 지향개발 경험이 적은 개발자는 위와 같은 처리들을 모두 한 객체에 몰아넣고 맙니다. 그리고 그 클래스에 OrderManager, Order Service라는 이름을 붙이는 것입니다. 그러한 설계를 했을 경우, Order, Customer, Item 과 같은 클래스는 레코드형과 다를 바 없게 됩니다. 세 가지의 클래스에서 로직이 완전히 배제되어, 수많은 if-then-else로 이루어진 하나의 큰 절차형 메소드에 처리를 맡기게 됩니다. 그런 메소드에서는 버그가 발생하기 쉽고, 유지보수도 어려워집니다. 왜냐하면, 동작의 캡슐화가 되어 있지 않기 때문입니다.


    상태만을 캡슐화하더라도, 동작의 캡슐화가 되어 있지 않으면 의미가 없습니다. 프로그래밍 언어에는 동작의 캡슐화를 위한 기능이 준비되어 있으므로 이를 적극적으로 활용하도록 합시다.


    저자: Einar Landre

    25년의 경험을 가진 소프트웨어의 프로.

    스트래스클라이드 대학에서 정보기술 이학 석사 학위를 취득했다.

    CSDP(IEEE-certified software development professional: IEEE 인정 소프트웨어 개발 프로패셔널 자격)을 갖고 있다.

    개발자, 아키텍트, 매니저, 컨설턴트로서의 일 외에 집필이나 프레젠테이션도 열심이다.

    지금은 StatoilHydro의 비즈니스 애플리케이션 서비스 부서에 근무하고, 크리티컬한 업무 애플리케이션 개발, 아키텍처 리뷰, 소프트웨어 프로세스 개선등을 담당하고 있다.

    StatoilHydro에 입사하기 전에는 개발자, 컨설턴트, 매니저로 국제 우주 정거장용 통신 프로토콜, OS, 테스트 소프트웨어 디자인, 코딩까지 참여했다.

    최근에는 프로패셔널 커뮤니티에도 적극적으로 참여하여 논문을 집필, 공동 집필하거나 하고 있으며, OOPSLA와 SPE(Society of Petroleum Engineers: 석유기술협회)에서 프레젠테이션을 하거나 한다.

    가족과 함께 노르웨이의 스타방에르에 살고 있다.


    [프로그래머] 상태뿐만 아니라 '동작'도 캡슐화 하라


    [출처] プログラマが知るべき97のこと (O'Reilly Japan)

    이 글은 [CC-by-3.0-US]에 의해 라이센스 되었습니다.




    댓글 0

Designed by Tistory.