GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software)47 GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 디자인 패턴 카탈로그(3장 생성 패턴) [디자인 패턴 카탈로그] [Chapter3 생성 패턴] 생성 패턴(creational pattern)은 인스턴스를 만드는 절차를 추상화하는 패턴이다. 이 범주에 해당하는 패턴은 객체를 생성,합성하는 방법이나 객체의 표현 방법과 소프트웨어 시스템을 분리해 준다. 클래스 생성 패턴이 인스턴스로 만들 클래스를 다양하게 만들기 위한 용도로 상속을 사용하는 반면, 객체 생성 패턴은 인스턴스화 작업을 다른 객체에게 떠넘길 수도 있다. 생성 패턴이 나오면 항상 따라다니는 이야기가 두 개가 있다. 첫째, 생성 패턴은 시스템이 어떤 구체 클래스를 사용하는지에 대한 정보를 캡슐화한다. 둘째, 생성 패턴은 이들 클래스의 인스턴스들이 어떻게 만들고 어떻게 서로 맞붙는지에 대한 부분을 완전히 가려준다. 결론적으로, 생성 패턴을.. 2020. 4. 16. GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.8~2.9) [순회, 그리고 순회 중의 작동] 순회와 순회 중 작동을 따로 떼어놓을 수 있다면 훨씬 더 높은 유연성과 재사용성을 얻을 수 있다. 분석 방법마다 사용되는 순회 방법이 한 가지가 아니라 여러 가지이기 때문이다. 분석과 순회는 분리해야 한다. 분석 방법은 글리프의 종류를 구별할 수 있어야 한다. 쉽게 생각할 수 있는 한 가지 방법은 분석 기능을 Glyph 클래스 자체에 넣는 것이다. 이 방법의 문제는 새로운 분석이 추가될 때마다 모든 Glyph 클래스를 변경해야 한다는 것이다. [분석 작업을 캡슐화하기] 분석 작업 자체를 별도의 객체로 캡슐화할 필요가 있다. 분석 작업을 나타내는 별도의 클래스를 정의하고, 이 클래스의 인스턴스를 반복자와 함께 사용한다. 반복자는 문서 구조를 이루는 원소들을 하나씩 순회하고.. 2020. 4. 15. GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.8) [2.8 철자 검사 및 붙임표 연결] 다양한 기능이 계속적으로 추가될 수 있는 틀을 만들고 싶다. 그러나 이런 기능을 추가할 때마다 Glyph 클래스나 이를 상속하는 서브클래스들을 변경하고 싶지는 않다. 이 퍼즐을 풀려면 두가지 조각을 맞춰야 한다. 1.하나는 분석될 정보에 접근하는 것인데, 이 정보는 문서 구조를 나타내는 여러 글리프에 흩어져 있다. 2.다른 하나는 분석을 직접 하는 것이다. [흩어진 정보에 대한 접근] 우리가 분석해야 하는 텍스트는 글리프 객체의 계층 구조에 흩어져 있다. Lexi에서 쓰는 접근 방법은 서로 다른 데이터 구조를 포괄할 수 있어야 하며, 서로 다른 순회 방법[postorder, inorder, preorder 등]이 지원되어야 한다. [접근과 순회 방법을 캡슐화하기] 글.. 2020. 4. 14. GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.7) [2.7 사용자 조작] WYSIWYG. 즉, 텍스트를 입력,삭제하며 삽입 지점으로 커서를 이동하고 텍스트의 범위를 선택하는 기능은 문서 화면을 마우스로 직접 클릭하고 키보드로 타이핑함으로써 가능하다. 사용자 조작을 어느 특정 사용자 인터페이스에만 국한시키고 싶지는 않다. 왜냐하면 여러 개의 사용자 인터페이스가 동일한 연산을 수행할 수도 있기 때문이다. 예를 들어, 페이지를 바꾸기 위해서 메뉴를 이용할 수도 있고, 페이지 이동 버튼을 이용할 수도 있다. 게다가, 한 가지의 조작 기능은 여러 다른 클래스들에서 구현된다. 구현자 쪽에서는 이런 기능을 위해 구현과 사용자 인터페이스 클래스 사이에 종속성을 만든느 일은 하지 않으려고 한다. 결합도가 강한 구현을 만들게 되면 이해하기도 어렵고 확장이나 유지보수가 어.. 2020. 4. 13. GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.6) [2.6 다중 윈도우 시스템 지원] [추상 팩토리 패턴을 사용할 수 있을까요?] 윈도우 시스템 간의 이식성은 앞에서 본 룩앤필 표준에 대한 독립성과는 사뭇 다른 점이 있다. 추상 팩토리 패턴을 적용할 때는 각 룩앤필별로 정확한 위젯 클래스를 정의할 것이라고 가정했다. 즉, 각 위젯별로 하나의 추상 클래스를 추출할 수 있어 추상 팩토리 패턴의 사용이 가능하다. 윈도우 시스템은 각 회사마다 서로 다른 여러 개의 클래스 게층을 이미 가지고 있는데, 이 계층이 서로 호환 가능하다고 볼 수 없기 때문에 각각 위젯별로 공통의 추상 클래스를 정의할 수 없다. 이때는 추상 팩토리 패턴을 적용할 수 없으므로, 제품이 갖는 인터페이스에서 공통된 연산을 정의하는 별도의 위젯 계층을 만들어야 한다. 그래도 다행인 점은 룻앤필.. 2020. 4. 12. GoF의 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software) - 2장 사례 연구:문서 편집기 설계(2.5) [2.5 다양한 룩앤필 표준 지원] 하드웨어와 소프트웨어 플랫폼 간의 이식성을 지원하는 것은 시스템 설게에 매우 중요한 일이다. 이식성에서 걸림돌이 되는 한 가지는 룩앤필 표준의 다양성이다. 이 표준은 응용프로그램이 어떻게 화면에 표시되고 어떻게 사용자의 요청에 반응하는지에 대한 표준 지침을 정의한다. 모티프를 기반으로 한 응용프로그램들은, 다른 플랫폼에서 이에 상응하는 응용프로그램과 완전히 똑같은 룩앤필을 갖고 있지는 않는다. 하나 이상의 플랫폼에서 돌아가는 응용프로그램은 그 플랫폼에서 제공하는 고유한 사용자 인터페이스 스타일 지침을 따라야 한다. 런타임에도 룩앤필을 변경할 수 있는, 최고의 유연성을 지원하는 설계는 만드는 것이 목표이다. [객체 생성의 추상화] 우리 눈에 보이고 Lexi의 사용자 인터.. 2020. 4. 11. 이전 1 ··· 3 4 5 6 7 8 다음