{"time":1752648351313,"blocks":[{"id":"wcToT4MHyO","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다. ","message":""}},{"id":"C1hOZ8GYVd","type":"customLink","data":{"url":"https://www.inflearn.com/course/%EC%98%A4%EB%B8%8C%EC%A0%9D%ED%8A%B8-%EA%B8%B0%EC%B4%88%ED%8E%B8-%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5","title":"오브젝트 - 기초편 강의 | 조영호 - 인프런","description":"조영호 | 책임 주도 설계 방법으로 대표되는 객체지향 설계 방법을 학습하고 응집도, 결합도, 캡슐화 관점에서 설계를 트레이드오프하는 방법을 살펴봅니다., 객체지향 설계의 핵심을 담았다!이 강의는 제가 집필한 오브젝트라는 책을 기반으로 책임 주도 설계 방법에 따라 객체 사이","image":"https://cdn.inflearn.com/public/files/courses/334416/cover/01jv93tqa0rq8w2m6dyzmrr1xj"}},{"id":"UJgHnbhq_-","type":"delimiter","data":{}},{"id":"rdEb39_3NT","type":"paragraph","data":{"text":"사람의 기억은 단기 기억(short-term memory) 과 장기 기억 (long-term memory) 으로 분류할 수 있다. 장기 기억은 경험한 내용을 수개월에서 길게는 평생에 걸쳐 보관하는 저장소를 의미한다. 장기기억은 매우 큰 저장 용량을 가지고 있으며 그 용량은 거의 무한대에 이르는 것으로 알려져 있다. "}},{"id":"E9011FzcNt","type":"paragraph","data":{"text":"일반적으로 장기 기억 안에 보관돼 있는 지식은 직접 접근하는 것이 불가능하고 먼저 단기 기억 영역으로 옮긴 후에 처리해야 한다. "}},{"id":"L8KvNi5yxy","type":"paragraph","data":{"text":"이에 비해 단기 기억은 보관돼 있는 지식에 직접 접근할 수 있지만 정보를 보관할 수 있는 속도와 공간적인 측면 모두에서 제약을 받는다. "}},{"id":"LLNpt0OBwq","type":"paragraph","data":{"text":"여기서 핵심은 실제로 문제를 해결하기 위해 사용하는 저장소는 장기 기억이 아니라 단기 기억이라는 점이다. 문제를 해결하기 위해서는 필요한 정보들을 먼저 단기 기억 안으로 불러들여야 한다. 그러나 문제 해결에 필요한 요소의 수가 단기 기억의 용량을 초과하는 순간 문제 해결 능력은 급격하게 떨어지고 만다. 이런현상을 인지 과부하 라고 부른다,"}},{"id":"ijIl5q8r3r","type":"paragraph","data":{"text":"인지 과부하를 방지하는 가장 좋은 방법은 단기 기억 안에 보관할 정보의 양을 조절하는 것이고, 이처럼 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 '추상화' 라고 부른다."}},{"id":"vS-t57Gr-Y","type":"paragraph","data":{"text":"그리고 추상화 방법은 한 번에 다뤄야 하는 문제의 크기를 줄이는 것이고, 큰 문제를 해결 가능한 작은 문제로 나누는 작업을 '분해' 라고 부른다."}},{"id":"NuIoqk3f_6","type":"warning","data":{"title":"한번에 단기 기억에 담을 수 있는 추상화의 수에는 한계가 있지만 추상화를 더 큰 규모의 추상화로 압축시킴으로써 단기 기억의 한계를 초월할 수 있다. 따라서 추상화와 분해가 인류가 창조한 가장 복잡한 분야의 문제를 해결하기 위해 사용돼 왔다고 해도 놀랍지 않을 것이다. 그 분야는 바로 소프트웨어 개발 영역이다. ","message":""}},{"id":"SQeRbiJlVx","type":"delimiter","data":{}},{"id":"VqWAPrxMPH","type":"customHeader","data":{"text":"급여 관리 시스템 구현 (예시)"}},{"id":"TDYc9ctlgh","type":"paragraph","data":{"text":"급여 관리 시스템의 최상위 문장 "}},{"id":"DQnDuJ_iku","type":"code","data":{"code":"직원의 급여를 계산한다."}},{"id":"PasVCgNc1g","type":"paragraph","data":{"text":"이 문장은 하나의 메인 함수로 매핑된다. 앞에서 급여를 계산하는데 필요한 소득세율은 사용자로부터 입력받고 직원의 기본급 정보는 시스템에 저장된 값을 참조하기로 결정했었다. 그리고 직원에 대한 정보를 찾기 위해 필요한 직원의 이름은 함수의 인자로 받기로 결정했었다. 따라서 급여 관리 시스템의 최상이 문장을 다음과 같은 함수 정의로 바꿀 수 있다. "}},{"id":"ek6-6mViJa","type":"code","data":{"code":"def main(name)\nend \n"}},{"id":"mMYhop5_fQ","type":"paragraph","data":{"text":"위의 세 단계는 모두 더 작은 세부적인 단계로 분해 가능하기 때문에 각 단계를 프로시저를 호출하는 명령문으로 변환할 수 있다. "}},{"id":"Ae_BbLY4IW","type":"code","data":{"code":"def main(name)\n taxRate = getTaxRate()\n pay = calculatePayFor(name, taxRate)\n puts(describeResult(name, pay)\nend"}},{"id":"NfFBzn7Zoz","type":"paragraph","data":{"text":"사용자로부터 소득세율을 입력받는 getTaxRate 함수는 다음과 같은 두 개의 절차로 분해할 수 있다. 이 절차는 언어나 라이브러리에서 제공하는 기능을 이용해 충분히 구현 가능한 수준이다. 따라서 getTaxRate 함수를 다음과 같이 구현할 수 있다. "}},{"id":"8X1NoIuDp4","type":"code","data":{"code":"def getTaxRate()\n print(\"세율을 입력하세요: \")\n returns gets().chomp().to_f()\nend"}},{"id":"tYE_Ztc5a7","type":"paragraph","data":{"text":"급여를 계산하는 코드는 기본급 정보를 이용해 급여를 계산하는 두 개의 단계로 구현할 수 있다. 직원의 목록은 $employees 라는 전역변수에, 직워별 기본급은 $basePays 라는 전역변수에 저장하기로 한다. 직원의 목록은 $employees 라는 전역변수에, 직원별 기본급은 $basePays 라는 전역변수에 저장하기로 한다. "}},{"id":"S4XgT-MkEX","type":"paragraph","data":{"text":"$employees 와 $basePays는 배열로 구현하며 동일한 직원에 대한 이름과 기본급 정보는 두 배열 내의 동일한 인덱스에 저장하기로 한다. 따라서 아래 코드에서 $employees 배열 안에서 '직원A'는 첫 번째 인덱스에 저장돼 있기 때문에 급여는 $basePays의 첫번 째 인덱스에 저장된 400 이다. "}},{"id":"NJflL9kOt5","type":"code","data":{"code":"$employees = [\"직원A\", \"직원B\",\"직원C\"]\n$basePays = [400, 300, 250]"}},{"id":"bY2CnfEzPi","type":"paragraph","data":{"text":"급여를 계산하는 calculatePayFor 함수는 파라미타로 전달된 직원의 이름을 $employees 배열 안에서의 인덱스를 알아낸 후 $basePays 의 해당 인덱스에 위치한 기본급 정보를 얻는다. 지급될 급여는 '기본급 - (기본급 * 소득세율)' 의 공식에 따라 계산된 후 반환된다."}},{"id":"OTgghTJ595","type":"code","data":{"code":"def calculatePayFor(name, taxRate)\n index = $employees.index(name)\n basePay = $basePay[index]\n return basePay - ( basePay * taxRate)\nend"}},{"id":"PHDGa0B1ye","type":"paragraph","data":{"text":"describeResult 함수는 이름과 급여 정보를 이용해 출력 포맷에 따라 문자열을 조합한 후 반환한다. "}},{"id":"S-K24kg3kc","type":"code","data":{"code":"def describeResult(name, pay)\n return \"이름: #{name}, 급여: #{pay}\"\nend"}},{"id":"d2-LWtKw_4","type":"paragraph","data":{"text":"이름이 \"직원 C\" 인 직원의 급여를 계산하려면 다음과 같이 프로시저를 호출하면 된다."}},{"id":"WXULuLV_2q","type":"code","data":{"code":"main(\"직원C\")"}},{"id":"kZnrxx6ma2","type":"paragraph","data":{"text":"예제에서 알수 있는 것처럼 하향식 기능 분해는 시스템을 최상위의 가장 추상적인 메인 함수로 정의하고, 메인 함수를 구현 가능한 수준까지 세부적인 단계로 분해하는 방법이다."}},{"id":"wlfF0sxmHz","type":"paragraph","data":{"text":"하향시 기능 분해 방식으로 설계한 시스템은 메인 함수를 루트로 하는 '트리(Tree)' 로 표현할 수 있다. 트리에서 각 노드(node) 는 시스템을 구성하는 하나의 프로시저를 의미하고 한 노드의 자식 노드는 부모 노드를 구현하는 절차중의 한 단계를 의미한다. "}},{"id":"OOOC-4PizS","type":"paragraph","data":{"text":"아래 그림은 현재가지 구현한 급여 관리 시스템을 트리 구조로 표현한 것이다. "}},{"id":"7pMFrFxQe3","type":"image","data":{"caption":"","withBorder":true,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/스크린샷_2025-07-14_오후_1.49.40.png"}}},{"id":"3XkpB-uVPs","type":"paragraph","data":{"text":"이처럼 하향식 기능 분해는 논리적으로 체계적인 시스템 개발 절차를 제시한다. 커다란 기능을 좀 더 작은 기능으로 단계적으로 정제해 가는 과정은 구조적이며 체계적인 동시에 이상적인 방법으로까지 보일 것이다. 문제는 우리가 사는 세계는 그렇게 체계적이지도, 이상적이지도 않다는 점이다. 체계적이고 이상적인 방법이 불규칙하고 불완전한 인간과 만나는 지점에서 혼란과 동요가 발생한다. "}},{"id":"ukXJNXUpcW","type":"delimiter","data":{}},{"id":"kAGRzWWAvt","type":"header","data":{"text":"하향식 기능 분해의 문제점 ","level":2}},{"id":"aO5xtwu0lB","type":"paragraph","data":{"text":"하향식 기능 분해 방법은 겉으로는 이상적인 방법으로 보일 수 있지만 실제로 설계에 적용하다 보면 다음과 같은 다양한 문제에 직면한다. "}},{"id":"5OtdR4Q92k","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"시스템은 하나의 메인 함수로 구성돼 있지 않다.","meta":{},"items":[]},{"content":"기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다.","meta":{},"items":[]},{"content":"비즈니스 로직이 사용자 인터페이스와 강하게 결합된다","meta":{},"items":[]},{"content":"하향식 분해는 너무 이른 시기에 함수들의 실행 순서를 고정시키기 때문에 유연성과 재사용성이 저하된다.","meta":{},"items":[]},{"content":"데이터 형식이 변경될 경우 파급효과를 예측할 수 없다.","meta":{},"items":[]}]}},{"id":"Vj6l70F28F","type":"paragraph","data":{"text":"설계는 코드 배치 방법이며 설계가 필요한 이유는 변경에 대비하기 위한 것이라는 점을 기억하라. 변경은 성공적인 소프트웨어가 맞이해야 하는 피할 수 없는 운명이다. 현재의 요구사항이 변하지 않고 코드를 변경할 필요가 없다면 소프트웨어를 어떻게 설계하건 아무도 신경 쓰지 않을 것이다. 하지만 불행하게도 소프트웨어는 항상 변경된다. "}},{"id":"HZwgoM2R8E","type":"delimiter","data":{}},{"id":"s_iRttPQoY","type":"header","data":{"text":"하나의 메인 함수라는 비현실적인 아이디어 ","level":3}},{"id":"Ly_BwUeO-4","type":"paragraph","data":{"text":"어떤 시스템도 최초에 릴리스됐던 당시의 모습을 그대로 유지하지는 않는다. 시간이 지나고 사용자를 만족시키기 위한 새로운 요구사항을 도출해나가면서 지속적으로 새로운 기능을 추가하게 된다. 이것은 시스템이 오직 하나의 메인 함수만으로 구현된다는 개념과는 완전히 모순된다. "}},{"id":"M_Vpslc01Z","type":"paragraph","data":{"text":"대부분의 경우 추가되는 기능은 최초에 배포된 메인 함수의 일부가 아닐 것이다. 결국 처음에는 중요하게 생각됐던 메인 함수는 동등하게 중요한 여러 함수들 중 하나로 전락하고 만다. "}},{"id":"8TF8B8ySS8","type":"paragraph","data":{"text":"어느 시점에 이르면 유일한 메인함수라는 개념은 의미가 없어지고 시스템은 여러 개의 동등한 수준의 함수 집합으로 성장하게 될 것이다. 현재 사용 중인 시스템 중 하나를 골라 전체 기능을 트리로 정리해보자. 모든 기능을 자식 노드로 가지는 하나의 메인 기능을 선택할 수 있겠는가? 생각보다 어렵다는 것을 알 수 있을 것이다."}},{"id":"oR78Evymk4","type":"paragraph","data":{"text":"하향식 접근법은 하나의 알고리즘을 구현하거나 배치 처리를 구현하기에는 적합하지만 현대적인 상호작용 시스템을 개발하는 데는 적합하지 않다. 현대적인 시스템은 동드한 수준의 다양한 기능으로 구성된다. 버트란도 마이어의 말을 인용하자면, \"실제 시스템에 정상(top)' 이란 존재하지 않는다\" "}},{"id":"4Nde5xho9G","type":"delimiter","data":{}},{"id":"kDGzq0IVus","type":"header","data":{"text":"비즈니스 로직과 사용자 인터페이스의 결합","level":3}},{"id":"hbImH-PnbR","type":"paragraph","data":{"text":"하향식 접근법은 비즈니스 로직을 설계하는 초기 단계부터 입력 방법과 출력 양식을 함께 고민하도록 강요한다. 급여를 계산하는 기능의 경우 \"사용자로부터 소득세율을 입력받아 급여를 계산한 후 계산된 결과를 화면에 출력한다\" 라는 말에는 급여를 계산하는 중요한 비즈니스 로직과 관련된 관심사와 소득세율을 입력받아 결과를 화면에 출력한다는 사용자 인터페이스의 관심사가 한데 섞여 있다는 것을 의미한다"}},{"id":"dClzZAQoIG","type":"paragraph","data":{"text":"문제는 비즈니스 로직과 사용자 인터페이스가 변경되는 빈도가 다르다는 것이다. 사용자 인터페이스는 시스템 내에서 가장 자주 변경되는 부분이다. 반면 비즈니스 로직은 사용자 인터페이스에 비해 변경이 적게 발생한다. "}},{"id":"3e7-2m2I7E","type":"paragraph","data":{"text":"하향식 접근법은 사용자 인터페이스 로직과 비즈니스 로직을 한데 섞기 때문에 사용자 인터페이스를 변경하는 경우 비즈니스 로직까지 변경에 영향을 받게 된다. 따라서 하향식 접근법은 근본적으로 변경에 불안정한 아키텍처를 낳는다. "}},{"id":"q1RJYtb4qs","type":"delimiter","data":{}},{"id":"wXlINDAfdQ","type":"header","data":{"text":"성급하게 결정된 실행 순서","level":3}},{"id":"qPg1enC0y_","type":"paragraph","data":{"text":"하향식으로 기능을 분해하는 과정은 하나의 함수를 더 작은 함수로 분해하고, 분해된 함수들의 실행 순서를 결정하는 작업으로 요약할 수 있다. 이것은 설계를 시작하는 시점부터 시스템이 무엇(what) 을 해야 하는지가 아니라 어떻게(how) 동작해야 하는지에 집중하도록 만든다."}},{"id":"gIB8XXkxz0","type":"paragraph","data":{"text":"하향식 접근법의 설계는 처음부터 구현을 염두에 두기 때문에 자연스럽게 함수들의 실행 순서를 정의하는 시간 제약(temporal constraint)을 강요한다. 메인 함수가작은 함수들로 분해되기 위해서는 우선, 소득세율을 입력받고, 그 후에 입력받은 소득세율을 이용해 급여를 계산하고, 계산된 결과를 이용해 결과를 출력해야 한다. 급여 계산에 필요한 함수들의 실행 순서를 미리 결정하지 않는 한 기능 분해를 진행할 수 없다. "}},{"id":"-9W16Y7gVc","type":"paragraph","data":{"text":"실행 순서나, 조건, 반복과 같은 제어 구조를 미리 결정하지 않고는 분해를 진행할 수 없기에 기능분해 방식은 중앙집중 제어 스타일(centrailzed control style) 의 형태를 띌 수 밖에 없다. 결과적으로 모든 중요한 제어 흐름의 결정이 상위 함수에서 이뤄지고 하위 함수는 상위 함수의 흐름에 따라 적절한 시점에 호출된다."}},{"id":"E5cutBzEBB","type":"paragraph","data":{"text":"문제는 중요한 설계 결정사항인 함수의 제어 구조가 빈번한 변경의 대상이라는 점이다. 기능이 추가되거나 변경될 때마다 초기에 결정된 함수들의 제어 구조가 올바르지 않다는 것이 판명된다. 결과적으로 기능을 추가하거나 변경하는 작업은 매번 기존에 결정된 함수의 제어 구조를 변경하도록 만든다. "}},{"id":"fHTSsBCOsJ","type":"paragraph","data":{"text":"이를 해결할 수 있는 한 가지 방법은 자주 변경되는 시간적인 제약에 대한 미련을 버리고 좀 더 안정적인 논리적 제약 (logical contraint)을 설계의 기준으로 삼는 것이다. 객체지향은 함수 간의 호출 순서가 아니라 객체 사이의 논리적인 관계를 중심으로 설계를 이끌어 나간다. 결과적으로 전체적인 시스템은 어떠 한 구성요소로 제어가 집중되지 않고 여러 객체들 사이로 제어 주체가 분산된다. "}},{"id":"z3Hg40YoDx","type":"paragraph","data":{"text":"하향식 접근법을 통해 분해한 함수들은 재사용하기도 어렵다. 모든 함수는 상위 함수를 분해하는 과정에서 필요에 따라 식별되며, 그에 따라 상위 함수가 강요하는 문맥(context) 안에서만 의미를 가지기 때문이다. 재사용이라는 개념은 일반성이라는 의미를 포함한다는 점을 기억하라. 함수가 재사용 가능하려면 상위 함수보다 더 일반적이어야 한다. 하지만 하향식 접근법을 따를 경우 분해된 하위 함수는 항상 상위 함수보다 문맥에 더 종속적이다. 이것은 정확하게 재사용성과는 반대되는 개념이다. "}},{"id":"aT0kWUMmnp","type":"paragraph","data":{"text":"하향식 설계와 관련된 모든 문제의 원인은 결합도이다. 함수는 상위 함수가 강요하는 문맥에 강하게 결합된다. 함수는 함께 절차를 구성하는 다른 함수들과 시간적으로 강하게 결합돼 있다. 강한 결합도는 시스템을 변경에 취약하게 만들고 이해하기 어렵게 만든다. 강하게 결합된 시스템은 아주 사소한 변경만으로도 전체 시스템을 크게 요동치게 만들 수 있다. 현재의 문맥에 강하게 결합된 시스템은 혀재 문맥을 떠나 다른 문맥으로 옮겨갔을 때 재사용하기 어렵다. 가장 큰 문제는 전체 시스템의 핵심적인 구조를 결정하는 함수들이 데이터와 강하게 결합된다는 것이다. "}},{"id":"cKfLNQwCEt","type":"delimiter","data":{}},{"id":"z801AE2sRZ","type":"customHeader","data":{"text":"정보 은닉과 모듈 "}},{"id":"MDa1w2iakR","type":"paragraph","data":{"text":"앞에서 설명한 것처럼 시스템의 변경을 관리하는 기본적인 전략은 함께 변경되는 부분을 하나의 구현단위로 묶고 퍼블릭 인터페이스를 통해서만 접근하도록 만드는 것이다. 즉, 기능을 기반으로 시스템을 분해하는 것이 아니라 변경의 방향에 맞춰 시스템을 분해하는 것이다. "}},{"id":"fZC9EaLys8","type":"paragraph","data":{"text":"데이비드 파나스는 1972년에 발표한 (On the Criteria To be Used In Decomposing Systems Into Modules) 에서 소프트웨어 개발의 가장 중요한 원리인 동시에 가장 많은 오해를 받고 있는 정보 은닉 (Inforamtion hiding)의 개념을 소개했다."}},{"id":"r444Um9kko","type":"paragraph","data":{"text":"정보 은닉은 시스템을 모듈 단위로 분해하기 위한 기본 원리로 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야한다는 것이다 핵심이다. 데이비드 파나스는 시스템을 모듈로 분할하는 원칙은 외부에 유출돼서는 안되는 비밀의 윤곽을 따라야 한다고 주장한다. "}},{"id":"rBHOjVuJeK","type":"paragraph","data":{"text":"정보 은닉은 외부에 감춰야 하는 비밀에 따라 시스템을 분할하는 모듈 분할 원리다. 모듈은 변경될 가능성이 있는 비밀을 내부로 감추고, 잘 정의되고 쉽게 변경되지 않을 퍼블릭 인터페이스를 외부에 제공해서 내부의 비밀에 함부로 접근하지 못하게 한다. "}},{"id":"-uBvhW7ez6","type":"paragraph","data":{"text":"모듈과 기능 분해는 상호 배타적인 관계가 아니다. 시스템을 모듈로 분해한 후에는 각 모듈 내부를 구현하기 위해 기능 분해를 적용할 수 있다. 기능 분해가 하나의 기능을 구현하기 위해 필요한 기능들을 순차적으로 찾아가는 탐색의 과정이라면 모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정이다. "}},{"id":"a1qDO-HCXt","type":"paragraph","data":{"text":"비밀을 결정하고 모듈을 분해한 후에는 기능 분해를 이용해 모듈에 필요한 퍼블릭 인터페이스를 구현할 수 있다. "}},{"id":"UpCncLyJ04","type":"paragraph","data":{"text":"모듈은 다음과 같은 2가지 비밀을 감춰야 한다. "}},{"id":"A9CqhbzTc9","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"복잡성","meta":{},"items":[{"content":"모듈이 너무 복잡한 경우 이해하고 사용하기가 어렵다. 외부에 모듈을 추상화할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다 ","meta":{},"items":[]}]},{"content":"변경 가능성","meta":{},"items":[{"content":"변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생했을 때 파급효과가 커진다. 변경 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.","meta":{},"items":[]}]}]}},{"id":"bkpMQcSSvJ","type":"delimiter","data":{}},{"id":"gfO2MJBFgE","type":"paragraph","data":{"text":"다음은 전체 직원에 관한 처리를 Employees 모듈로 캡슐화한 결과를 나타낸 것이다."}},{"id":"T0Tb1Rx_5I","type":"code","data":{"code":"module Employess\n $employees = [\"직원A\",\"직원B\",\"직원C\",\"직원D\",\"직원E\"]\n $basePays = [400, 300, 250, 1, 1, 1.5]\n $hourlys = [false,false,false,true,true,true]\n $timeCards = [0, 0, 0, 120, 120, 120]\n\ndef Employees.calculatePay(name, taxRate)\n if (Employees.hourly?(name)) then\n pay = Employees.calculateHourlyPayFor(name, taxRate)\n else\n pay = Employees.calcupatePayFor(name, taxRate)\n end\nend\n\ndef Employees.hourly?(name)\n return $hourlys[$employees.index(name)]\nend\n\ndef Employees.calculateHourlyPayFor(name, taxRate)\n index = $employees.index(name)\n basePay = $basePays[index] * $timeCards[index]\n return basePay - ( basePay * taxRate)\nend \n\ndef Employees.calculatePayFor(name, taxRate)\n return basePay - (basePay * taxRate)\nend\n\ndef Employees.sumOfBasePays()\n result = 0\n for name in $employees\n if (not Employees.hourly?(name)) then\n result += $basePays[$employees.index(nmae)]\n end\n end\n return result\nend"}},{"id":"CAIY6ZZruc","type":"paragraph","data":{"text":"지금까지 전역변수 였던애들을 Employees 라는 모듈 내부로 숨겨져 있다는 것에 주목하라. 이제 모듈 외부에서는 직원 정보를 관리하는 데이터에 직접 접근할 수 없다. 외부에서는 Employees 모듈이 제공하는 퍼블릭 인터페이스에 포함된 calculatePay, hourly?, calculateHourlyPayFor, calculatePayFor, sumofBasePays 함수를 통해서만 내부 변수를 조작할 수 있다. 심지어 모듈 외부에서는 모듈 내부에 어떤 데이터가 존재하는지 조차 알지 못한다."}},{"id":"9UlKnMvd0Z","type":"paragraph","data":{"text":"이제 main 함수가 Employees 모듈의 기능을 사용하도록 코드를 수정하면 된다 "}},{"id":"b_ZyeTsKwX","type":"code","data":{"code":"def main(operation, args={})\n case(operation)\n when :pay then calculatePay(args[:name])\n when :basePay then sumOfBasePays()\n end\nend \n\ndef calculatePay(name)\n taxRate = getTaxRate()\n pay = Employees.calculatePay(name, taxRate)\n puts(describeResult(name,pay))\nend\n\ndef getTaxRate()\n print(\"세율을 입력하세요: \")\n return gets().chomp().to_f()\nend \n\ndef describeResult(name, pay)\n return \"이름: #{name}, 급여: ${pay}\"\nend \n\ndef sumOfBasePays()\n puts(Employees.sumOfBasePays())\nend "}},{"id":"r-yvKU8gXe","type":"delimiter","data":{}},{"id":"GFx18TdQQx","type":"header","data":{"text":"모듈의 장점과 한계","level":2}},{"id":"E1-fKbgUSR","type":"paragraph","data":{"text":"Employees 예제를통해 알 수 있는 모듈의 장점은 다음과 같다. "}},{"id":"CMc9u4-r8W","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다","meta":{},"items":[]},{"content":"비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다","meta":{},"items":[]},{"content":"전역 변수와 전역 함수를 제거함으로써 네임스페이스 오염을 방지한다.","meta":{},"items":[]}]}},{"id":"dL6aAzfjKq","type":"paragraph","data":{"text":"모듈은 기능이 아니라 변경의 정도에 따라 시스템을 분해하게 한다. 각 모듈은 외부에 감춰야 하는 비밀과 관련성높은 데이터와 함수의 집합이다. 따라서 모듈 내부는 높은 응집도를 유지한다. 모듈과 모듈 사이에는 퍼블릭 인터페이스를 통해서만 통신해야 한다. 따라서 낮은 결합도를 유지한다. "}},{"id":"Qzvuf4axfW","type":"delimiter","data":{}},{"id":"3PtAcHq2q1","type":"header","data":{"text":"협력이 중요하다","level":2}},{"id":"sJcy3zWUAp","type":"paragraph","data":{"text":"단순하게 오퍼레이션과 타입을 표에 적어 놓고 클래스 계층에 오퍼레이션의 구현 방법을 분배한다고 해서 객체지향적인 애플리케이션을 설계하는 것은 아니다. "}},{"id":"aK3Cl-IQqt","type":"paragraph","data":{"text":"객체지향에서 중요한 것은 역할, 책임, 협력이다. 객체지향은 기능을 수행하기 위해 객체들이 협력하는 방식에 집중한다. 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션의 구현 방식을 타입별로 분배하는 것은 올바른 접근법이 아니다."}},{"id":"ZP61Tvz7PT","type":"paragraph","data":{"text":"객체가 참여할 협력을 결정하고 협력에 필요한 책임을 수행하기 위해 어떤 객체가 필요한지에 관해 고민하라. 그 책임을 다양한 방식으로 수행해야 할 때만 타입 계층 안에 각 절차를 추상화하라, 타입 계층과 다형성은 협력이라는 문맥 안에서 책임을 수행하는 방법에 관해 고민한 결과물이어야 하며 그 자체가 목적이 되어서는 안된다."}}],"version":"2.31.0-rc.7"}

Tag List