{"time":1753197707040,"blocks":[{"id":"85elOBAgew","type":"warning","data":{"title":"해당 글은 조영호님의 쓰신 Object 책을 읽고 챕터별로 정리해본 글입니다. ","message":""}},{"id":"4zPB3y-yqc","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":"aaAb1imL3h","type":"delimiter","data":{}},{"id":"HOnaeuqRq9","type":"paragraph","data":{"text":"애플리케이션을 설계하다보면 어떤 요구사항을 해결하기 위해 과거에 경험했던 유사한 해결 방법을 다시 사용하는 경우가 있다. 이처럼 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다."}},{"id":"XO2EjbCkeP","type":"paragraph","data":{"text":"디자인 패턴의 목적은 설계를 재사용하는 것이다. 디자인 패턴은 다양한 변경을 다루기 위해 반복적으로 재사용할 수 있는 설계의 묶음이다. 일단 디자인 패턴을 익히고 나면 변경의 방향과 주기를 이해하는 것 만으로도 필요한 역할과 책임, 역할들의 협력 방식을 순간적으로 떠올릴 수 있게 된다."}},{"id":"LN0fHoJstl","type":"paragraph","data":{"text":"디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 재사용하기 위한 것이다. 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다. 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 다양한 환경에서 테스트를 거친 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다. 프레임워크는 각 애플리케이션이 요구에 따라 적절하게 커스터마이징 할 수 있는 확장 포인트를 제공한다."}},{"id":"dGKCFN46tn","type":"paragraph","data":{"text":"디자인 패턴과 프레임워크 모두 14장에서 살펴본 일관성 있는 협력과 관련이 있다. 디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공한다. 프레임워크는 특정한 변경을 일관성 있게 다를 수 있는 확장 가능한 코드 템플릿을 제공한다."}},{"id":"l_CnXYbmxA","type":"paragraph","data":{"text":"디자인 패턴이 협력을 일관성 있게 만들기 위해 재사용할 수 있는 설계의 묶음이라면, 프레임워크는 일관성 있는 협력을 제공하는 확장 가능한 코드라고 할 수 있다. 결론적으로 디자인 패턴과 프레임워크 모두 협력을 일관성 있게 만들기 위한 방법이다. "}},{"id":"okXNjE3Rau","type":"delimiter","data":{}},{"id":"_f-Aan1Ksf","type":"header","data":{"text":"디자인 패턴과 설계 재사용","level":2}},{"id":"BniKsn9-pX","type":"header","data":{"text":"소프트웨어 패턴","level":3}},{"id":"3r7NH7Ypul","type":"paragraph","data":{"text":"워드 커닝험과 켄트 백이 크리스토퍼 알렉산더의 패턴 개념을 소프트웨어 개발 커뮤니티에 소개한 때부터 패턴은 항상 소프트웨어 개발에 있어 중요한 화두가 되어왔다. GOF 가 저술한 <GOF의 디자인 패턴> 에 의해 패턴이 대중화 된 이후 소프트웨어와 관련된 패턴을 다루는 수많은 저작물이 쏟아져 나왔으며 그에 비례해서 패턴의 정의 역시 다양하고 풍부해져 왔다. 패턴이라는 거대한 숲 속에서 길을 잃지 않기 위해서는 패턴의 정의보다는 패턴이라는 용어자체가 풍기는 미묘한 늬앙스를 이해하는 것이 중요하다."}},{"id":"yDEcnrFZpA","type":"paragraph","data":{"text":"패턴이란 무엇인가를 논의할 때면 반복적으로 언급되는 몇 가지 핵심적인 특징이 있다. "}},{"id":"jk8dj5cNAF","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다","meta":{},"items":[]},{"content":"패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다","meta":{},"items":[]},{"content":"패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 매워주며 실질적인 코드 작성을 돕는다","meta":{},"items":[]},{"content":"패턴의 요점은 패턴이 실무에서 탄생했다는 것이다.","meta":{},"items":[]}]}},{"id":"Zvgtl8J9NG","type":"delimiter","data":{}},{"id":"4Pzci1mV7N","type":"paragraph","data":{"text":"패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 아이디어다. 일반적으로 패턴으로 인정하기 위한 조건으로 '3의 규칙(Rule of Three)' 를 언급한다"}},{"id":"MIc_Z76LFz","type":"paragraph","data":{"text":"이 규칙에 따르면 최소 3가지의 서로 다른 시스템에 특별한 문제 없이 적용할 수 있고 유용한 경우에만 패턴으로 간주할 수있다. "}},{"id":"FpHq2KxSEk","type":"paragraph","data":{"text":"패턴이 지는 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다. 패턴은 경험의 산물이다. 책상 위에서 탄생한 이론이나 원리와 달리 패턴은 치열한 실무 현장의 역학관계 속에서 검증되고 입증된 자산이다. 따라서 실무 경험이 적은 초보자라고 하더라도 패턴을 익히고 반복적으로 적용하는 과정 속에서 유연하고 품질 높은 소프트웨어를 개발하는 방법을 익힐 수 있게 된다."}},{"id":"0XmOZQFoSw","type":"paragraph","data":{"text":"패턴의 이름은 커뮤니티가 공유할 수 있는 중요한 어휘집을 제공한다. 잘 알려진 이름을 사용함으로써 \"인터페이스를 하나 추가하고 이 인터페이스를 구체화하는 클래스를 만든 후 객체의 생성자는 setter 메서드에 할당해서 런타임 시에 알고리즘을 바꿀 수 있게 하자\"는 장황한 대화가 STRATEGY 패턴을 적용하자는 단순한 대화로 바뀐다. "}},{"id":"0ykGopwJnY","type":"warning","data":{"title":"패턴의 이름은 높은 수준의 대화를 가능하게 하는 원천이다","message":""}},{"id":"EuFajjN7TR","type":"paragraph","data":{"text":"마틴 파울러가 언근한 것처럼 패턴의 범위가 소프트웨어 개발과 직접적인 연관성을 가진 분석, 설계, 구현 영역으로만 한정되는 것은 아니다. 다양한 크기의 프로젝트 조직을 구성하는 방법, 프로젝트 일정을 추정하는 방법, 스토리 카드나 백로그를 통해 요구사항을 관리하는 방법과 같이 반복적인 규칙을 발견할 수 있는 모든 영역이 패턴의 대상이 될 수 있다. "}},{"id":"49kGAanHx9","type":"delimiter","data":{}},{"id":"4liNSK5-Fz","type":"header","data":{"text":"패턴 분류 ","level":2}},{"id":"rtfBXR0kcI","type":"paragraph","data":{"text":"패턴을 분류하는 가장 일반적인 방법은 패턴의 범위나 적용 단계에 따라 아키텍처 패턴, 분석 패턴, 디자인 패턴, 이디엄 의 4가지로 분류하는 것이다. 4가지 중에서 가장 널리 알려진 것은 디자인 패턴이다. 디자인 패턴은 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다. "}},{"id":"X2RgGzSLrl","type":"paragraph","data":{"text":"디자인 패턴은 중간 규모의 패턴으로, 특정한 설계 문제를 해결하는 것을 목적으로 하며, 프로그래밍 언어나 프로그래밍 패러다임에 독립적이다. "}},{"id":"LZrhUC4tE5","type":"paragraph","data":{"text":"아키텍처 패턴, 디자인 패턴, 이디엄이 주로 기술적인 문제를 해결하는 데 초점을 맞추고 있다면, 분석패턴은 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춘다. 분석 패턴은 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다. 분석 패턴은 단 하나의 도메인에 대해서만 적절할 수 있고 여러 도메인에 걸쳐 적용할 수도 있다. "}},{"id":"O8OA4GeQc3","type":"delimiter","data":{}},{"id":"nyo7kZ78dt","type":"header","data":{"text":"패턴과 책임-주도 설계","level":2}},{"id":"uC7LVCiIPB","type":"paragraph","data":{"text":"객체지향 설계에서 가장 중요한 일은 올바른 책임을 올바른 객체에게 할당하고 객체 간의 유연한 협력관계를 구축하는 일이다. 책임과 협력의 윤곽은 캡슐화, 크기, 의존성, 유연성, 성능, 확장 가능성, 재사용성 등의 다양한 요소들의 트레이드오프를 통해 결정된다. "}},{"id":"2CsiPnYUvc","type":"paragraph","data":{"text":"가끔씩 책임과 협력을 결정하는 작업이 손쉽게 진행될 때도 있지만 대부분의 경우에는 훌륭한 품질의 설계를 얻기 위해 많은 시간과 노력을 들여야만 한다. 어떤 책임이 필요한가? 이 책임을 어떤 객체에게 할당해야 하는가? 유연하고 확장 가능한 협력관계를 구축하기 위해서는 객체와 객체 간에 어떤 의존성이 존재해야 하는가? "}},{"id":"-vEzPxWLGT","type":"paragraph","data":{"text":"패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. 패턴은 반복적으로 발생하는 문제를 해결하기 위해 사용할 수 있는 공통적인 역할과 책임, 협력의 훌륭한 예제를 제공한다. <GOF 의 디자인 패턴> 에 정리된 패턴을 예를 들어 설명하면 "}},{"id":"nfKRV5agYQ","type":"list","data":{"style":"unordered","meta":{},"items":[{"content":"STRATEGY 패턴은 다양한 알고리즘을 동적으로 교체할 수 있는 역할과 책임의 집합을 제공한다","meta":{},"items":[]},{"content":"BRIDGE 패턴은 추상화의 조합으로 인한 클래스의 폭발적인 증가 문제를 해결하기 위해 역할과 책임을 추상화와 구현의 두개의 커다란 집합으로 분해함으로써 설계를 확장 가능하게 만든다","meta":{},"items":[]},{"content":"OBSERVE 패턴은 유연한 통지 메커니즘을 구축하기 위해 객체 간의 결합도를 낮출 수 있는 역할과 책임의 집합을 제공한다 ","meta":{},"items":[]}]}},{"id":"DtI0hZG-RI","type":"paragraph","data":{"text":"여기서 언급한 패턴들의 세부적인 내용이 중요한 것이 아니다. 중요한 것은 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다는 사실이다. 특정한 상황에 적용 가능한 패턴을 잘 알고 있다면 책임 주도 설계의 절차를 하나하나 따르지 않고도 시스템 안에 구현할 객체들의 역할과 책임 협력 관계를 빠르고 손쉽게 구성할 수 있다. "}},{"id":"DzE3xdAxxi","type":"paragraph","data":{"text":"패턴의 구성 요소는 클래스가 아니라 '역할' 이다. 예를 들어 클라이언트가 개별 객체와 복합 객체를 동일하게 취급할 수 있는 COMPOSITE 패턴을 살펴보자. "}},{"id":"fFT_7d9Doz","type":"paragraph","data":{"text":"패턴의 구성 요소인 Componet, CompoSite, Leaf 는 클래스가 아니라 협력에 참여하는 객체들의 역할이다. Component 는 역할이기 때문에 Component 가 제공하는 오퍼레이션을 구현하는 어떤 객체라도 Component 의 역할을 수행할 수 있다."}},{"id":"S_V2X90qC8","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(21).png"}}},{"id":"1ZOGk-_VmY","type":"paragraph","data":{"text":"디자인 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책임이라는 사실을 이해하는 것이 중요하다. 어떤 구현 코드가 어떤 디자인 패턴을 따른다고 이야기 할때는 역할, 책임, 협력의 관점에서 유사성을 공유한다는 것이지 특정한 구현 방식을 강제하는 것은 아니라는 점을 이해하는 것 역시 중요하다. "}},{"id":"dTxNqT9Uvo","type":"delimiter","data":{}},{"id":"Ig-gOoUW3E","type":"header","data":{"text":"캡슐화와 디자인 패턴 ","level":2}},{"id":"0HxPSWsytf","type":"paragraph","data":{"text":"몇 가지 예외적인 경우를 제외하면 널리 알려진 대부분의 디자인 패턴은 협력을 일관성 있고 유연하게 만드는 것을 목적으로 한다. 따라서 각 디자인 패턴은 특정한 변경을 캡슐화하기 위한 독자적인 방법을 정의하고 있다. "}},{"id":"cY5hJEXOko","type":"paragraph","data":{"text":"영화 에매 시스템에서 Movie 가 DiscountPolicy 상속 계층을 합성 관계로 유지해야 하는 다양한 설계 원칙과 이유에 대해 장황하게 설명했지만 사실 이 설계는 STRATEGY 패턴을 적용한 예다. STRATEGY 패턴의 목적은 알고리즘의 변경을 캡슐화하는 것이고 이를 구현하기 위해 객체 합성을 이용한다. "}},{"id":"jwpt3cSoVd","type":"paragraph","data":{"text":"아래 그림은 STATEGY 패턴을 적용한 영화 예매 시스템 설계를 표현한 것이다. 영화에 적용될 할인 정책의 종류는 Movie 가 참조하는 DiscountPolicy 의 서브클래스가 무엇이냐에 따라 결정된다. 그리고 STRATEGY 패턴을 이용하면 Movie 와 DiscountPolicy 사이의 결합도를 낮게 유지할 수 있기 때문에 런타입에 알고리즘을 변경할 수 있다. "}},{"id":"8ON29D1oz5","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(22).png"}}},{"id":"FqM6vrebrl","type":"paragraph","data":{"text":"물론 변경을 캡슐화하는 방법이 합성만 있는 것은 아니다. 상속을 이용할 수도 있다. "}},{"id":"ZJhgLYvKk-","type":"paragraph","data":{"text":"아래 그림은 Movie 의 인터페이스 측면에서는 위 그림과 동일하지만 변경을 캡슐화하기 위해 상속을 사용한 예다. 여기서 변하지 않는 부분은 Movie 고 변하는 부분은 AmountDiscountMovie 와 PercentDiscountMovie 다. "}},{"id":"rAulbnhE6u","type":"paragraph","data":{"text":"그리고 변경하지 않는 부분은 부모 클래스로, 변하는 부분은 자식 클래스로 분리함으로써 변경을 캡슐화한다. 이처럼 알고리즘을 캡슐화하기 위해 합성 관계가 아닌 상속 관계를 사용한다는 것을 TEMPLATE METHOD 패턴이라고 부른다. "}},{"id":"9HKuLJbdoG","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":false,"file":{"url":"https://backend.owl-dev.me/images/image(23).png"}}},{"id":"VJ4aLsa507","type":"paragraph","data":{"text":"추상 클래스나 인터페이스를 사용해 변경을 캡슐화하는 합성과 달리 상속을 사용할 경우에는 추상 메서드를 이용해 변경을 캡슐화해야 한다. 위 그림에서 calculateDiscountAmount 메서드가 바로 서브클래스의 변경을 캡슐화하기 위해 사용되는 추상 메서드다. "}},{"id":"sj-sM3spAG","type":"paragraph","data":{"text":"부모 클래스의 calculateFee 메서드 안에서 추상 메서드인 calculateDiscountAmount 를 호출하고 자식 클래스들이 이 메서드를 오버라이딩해서 변하는 부분을 구현한다는 것이 중요하다. 이것은 TEMPLATE METHOD 패턴의 전형적인 구현 방법이다. "}},{"id":"N-IHYlnnly","type":"paragraph","data":{"text":"이처럼 TEMPLATE METHOD 패턴은 부모 클래스가 알고리즘의 기본 구조를 정의하고 구체적인 단계는 자식 클래스에서 정의하게 함으로써 변경을 캡슐화 할 수 있는 디자인 패턴이다. "}},{"id":"ab1YT1HRW7","type":"paragraph","data":{"text":"다만 합성보다는 결합도가 높은 상속을 사용했기 때문에 STRATEGY 패턴처럼 런타임에 객체의 알고리즘을 변경하는 것은 불가능하다. 하지만 알고리즘 교체와 같은 요구사항이 없다면 상대적으로 STATEGY 패턴보다 복잡도를 낮출 수 있다는 면에서는 장점이라고 할 수 있습니다."}},{"id":"REv-PgCAUh","type":"delimiter","data":{}},{"id":"h-C0ynDdTA","type":"paragraph","data":{"text":"아래 그림은 핸드폰 과금 시스템 설계는 DECORATOR 패턴을 기반으로 한다. DECORATOR 패턴은 객체의 행동을 동적으로 추가할 수 있게 해주는 패턴으로 기본적으로 객체의 행동을 결합하기 위해 객체 합성을 사용한다. DECORATOR 패턴은 선택적인 행동의 개수와 순서에 대한 변경을 캡슐화 할 수 있다. "}},{"id":"7QdJNH-zCR","type":"image","data":{"caption":"","withBorder":false,"withBackground":false,"stretched":true,"file":{"url":"https://backend.owl-dev.me/images/image(24).png"}}},{"id":"eM5Htm_v2q","type":"paragraph","data":{"text":"대부분의 디자인 패턴의 목적은 특정한 변경을 캡슐화함으로써 유연하고 일관성 있는 협력을 설계할 수 있는 경험을 공유하는 것이다. 디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니다. 어떤 디자인 패턴이 어떤 변경을 캡슐화하는지를 이해하는 것이 중요하다. 그리고 각 디자인 패턴이 변경을 캡슐화하기 위해 어떤 방법을 사용하는지를 이해하는 것이 더 중요하다. "}}],"version":"2.31.0-rc.7"}

Tag List