Onionmixer: 큰 따옴표

2013-01-20T07:32:08Z

큰 따옴표

← Older revision		Revision as of 07:32, 20 January 2013
Line 258:		Line 258:
	===예제 코드===		===예제 코드===

	Sharable 패턴의 한 가지 흔한 사용은 그래픽 아이콘을 관리할 때이다. 그래픽 사용자 인터페이스(GUI) 윈도우는 버튼 라벨, 메뉴 선택, 목록 항목 등과 같은 그래픽 아이콘을 나타내곤 한다. 종종 동일한 아이콘이 여러 장소에 사용된다. Help 아이콘은 ~~“Help”~~ 버튼과 Help 메뉴 선택에 모두 표시된다. 아이콘이 목록의 각 항목 상태를 나타내고 선택 가능한 상태가 몇 가지에 그친다면 목록에서 동일한 몇 개의 아이콘을 반복해 사용할 것이다.		Sharable 패턴의 한 가지 흔한 사용은 그래픽 아이콘을 관리할 때이다. 그래픽 사용자 인터페이스(GUI) 윈도우는 버튼 라벨, 메뉴 선택, 목록 항목 등과 같은 그래픽 아이콘을 나타내곤 한다. 종종 동일한 아이콘이 여러 장소에 사용된다. Help 아이콘은 "Help" 버튼과 Help 메뉴 선택에 모두 표시된다. 아이콘이 목록의 각 항목 상태를 나타내고 선택 가능한 상태가 몇 가지에 그친다면 목록에서 동일한 몇 개의 아이콘을 반복해 사용할 것이다.

	비주얼웍스에서 아이콘은 PixelArray/Image 계층구조의 인스턴스로 표시되고, 비주얼 스몰토크에서는 Icon 으로, IBM 스몰토크에선 CgIcon으로서 나타난다. 이번 예제에서는 비주얼웍스의 Image 클래스를 이용하고자 한다. Image는 자원 집중적으로 볼 수 있다; 엄청난 메모리를 소모한다ㅡ스몰토크 메모리, 윈도우 시스템 메모리 중 하나 또는 둘 다 소모한다. 따라서 동일한 아이콘을 여러 장소에 사용하고 각 장소에서 정확히 똑같은 모습으로 보일 예정이라면 그 모든 장소에 Image의 동일한 인스턴스를 사용하는 것이 효율적이다. Image는 한 번 생성되고 나면 그 내부 상태가 변하지 않기 때문에 이러한 상황에 효과가 있을 것이다. Image를 사용하는 위젯은 그 상태를 바꿔선 안 된다.		비주얼웍스에서 아이콘은 PixelArray/Image 계층구조의 인스턴스로 표시되고, 비주얼 스몰토크에서는 Icon 으로, IBM 스몰토크에선 CgIcon으로서 나타난다. 이번 예제에서는 비주얼웍스의 Image 클래스를 이용하고자 한다. Image는 자원 집중적으로 볼 수 있다; 엄청난 메모리를 소모한다ㅡ스몰토크 메모리, 윈도우 시스템 메모리 중 하나 또는 둘 다 소모한다. 따라서 동일한 아이콘을 여러 장소에 사용하고 각 장소에서 정확히 똑같은 모습으로 보일 예정이라면 그 모든 장소에 Image의 동일한 인스턴스를 사용하는 것이 효율적이다. Image는 한 번 생성되고 나면 그 내부 상태가 변하지 않기 때문에 이러한 상황에 효과가 있을 것이다. Image를 사용하는 위젯은 그 상태를 바꿔선 안 된다.
Line 303:		Line 303:
	</syntaxhighlight>		</syntaxhighlight>

	다음으로 Sharable 생성 메서드를 구현한다. 각 메서드는 Image를 생성하여 반환할 것이다. ~~“create~~<icon name>~~Icon”과~~ 같은 명명 규칙을 따르는 것이 도움이 된다. 예를 들어, Help 기능과 Save 기능에 대한 아이콘이 필요하다면 createHelpIcon과 createSaveIcon의 아이콘 생성 메서드의 이름을 지정해야 한다.		다음으로 Sharable 생성 메서드를 구현한다. 각 메서드는 Image를 생성하여 반환할 것이다. "create<icon name>Icon"과 같은 명명 규칙을 따르는 것이 도움이 된다. 예를 들어, Help 기능과 Save 기능에 대한 아이콘이 필요하다면 createHelpIcon과 createSaveIcon의 아이콘 생성 메서드의 이름을 지정해야 한다.

	어떠한 특정 클래스도 Help 아이콘의 책임을 갖지 없다고 치자. 그러면 Image에 기본으로 구현할 것이다. Image 인스턴스의 생성은 꽤 세부적이며 Sharable 패턴을 이해하는데 있어 그다지 중요하지 않다. 이미지에 대한 비트맵과 그것을 어떻게 만들지를 명시하는 수많은 파라미터를 가진 CachedImage class>>on:extent:depth:bitsPerPixel:palette:usingBits: 메서드의 실행을 수반한다고 말하면 충분하겠다. 예를 들어, 비주얼웍스 런처에 표시되는 도움말 책 이미지를 생성하고 반환하는 VisualLauncher class>>CGHelp32 메서드를 참조한다.		어떠한 특정 클래스도 Help 아이콘의 책임을 갖지 없다고 치자. 그러면 Image에 기본으로 구현할 것이다. Image 인스턴스의 생성은 꽤 세부적이며 Sharable 패턴을 이해하는데 있어 그다지 중요하지 않다. 이미지에 대한 비트맵과 그것을 어떻게 만들지를 명시하는 수많은 파라미터를 가진 CachedImage class>>on:extent:depth:bitsPerPixel:palette:usingBits: 메서드의 실행을 수반한다고 말하면 충분하겠다. 예를 들어, 비주얼웍스 런처에 표시되는 도움말 책 이미지를 생성하고 반환하는 VisualLauncher class>>CGHelp32 메서드를 참조한다.
Line 329:		Line 329:
	</syntaxhighlight>		</syntaxhighlight>

	이제 Image의 클래스 측에 SharableFactory가 있고 이는 Image Sharable을 생성하는 메서드를 가진다. 이제 필요한 것은 Sharable에 접근하기 위한 메서드 또는 메서드들이다. [디자인 패턴] 편에서는 getFlyweight : key와 같은 메서드의 사용을 제안한다. 하지만 Sharable의 수가 고정되어 있다면 각 Sharable마다 구분된 접근자 메서드를 구현하는 편이 쉽다. 생성 메서드를 위한 명명 규칙이 "create<icon name>Icon"이었던 것과 마찬가지로 접근 명명 규칙은 “<icon name>~~Icon”이~~ 되어야 한다.		이제 Image의 클래스 측에 SharableFactory가 있고 이는 Image Sharable을 생성하는 메서드를 가진다. 이제 필요한 것은 Sharable에 접근하기 위한 메서드 또는 메서드들이다. [디자인 패턴] 편에서는 getFlyweight : key와 같은 메서드의 사용을 제안한다. 하지만 Sharable의 수가 고정되어 있다면 각 Sharable마다 구분된 접근자 메서드를 구현하는 편이 쉽다. 생성 메서드를 위한 명명 규칙이 "create<icon name>Icon"이었던 것과 마찬가지로 접근 명명 규칙은 "<icon name>Icon"이 되어야 한다.

	따라서 helpIcon과 saveIcon은 다음과 같이 구현할 필요가 있겠다:		따라서 helpIcon과 saveIcon은 다음과 같이 구현할 필요가 있겠다:
Line 447:		Line 447:
	====Flyweight 패턴 대 Proxy 패턴====		====Flyweight 패턴 대 Proxy 패턴====

	Flyweight와 Proxy (213)는 매우 까다로운 패턴이긴 하나 주로 혼동되곤 한다. flyweight"란 이름을 들으면 개발자들은 실제 객체의 대체로 로드되는 가벼운(경량의) 객체를 생각할지도 모른다. 이는 사용자가 큰 객체의 큰 집합을 절대로 사용할 일이 없을 때 이러한 집합체로 로딩을 피하기 위한 공통 기법이다. 대신 경량의 대체 객체로 로드되고, 사용자가 실제로 사용하는 것은 실제 객체로 변환된다. 이는 완벽히 유효하면서도 공통된 패턴이지만 Flyweight는 아니다; Proxy 패턴에 해당한다. Flyweight는 다수의 클라이언트에 의해 투명하게 공유될 때 독립적 copy와 같은 역할을 하는 객체이다. Flyweight와 Proxy는 엄연히 다른 패턴이다; 속아 넘어가지 말자.		Flyweight와 Proxy (213)는 매우 까다로운 패턴이긴 하나 주로 혼동되곤 한다. flyweight 라는 이름을 들으면 개발자들은 실제 객체의 대체로 로드되는 가벼운(경량의) 객체를 생각할지도 모른다. 이는 사용자가 큰 객체의 큰 집합을 절대로 사용할 일이 없을 때 이러한 집합체로 로딩을 피하기 위한 공통 기법이다. 대신 경량의 대체 객체로 로드되고, 사용자가 실제로 사용하는 것은 실제 객체로 변환된다. 이는 완벽히 유효하면서도 공통된 패턴이지만 Flyweight는 아니다; Proxy 패턴에 해당한다. Flyweight는 다수의 클라이언트에 의해 투명하게 공유될 때 독립적 copy와 같은 역할을 하는 객체이다. Flyweight와 Proxy는 엄연히 다른 패턴이다; 속아 넘어가지 말자.

	====Flyweight 패턴과 Proxy, Adapter, Decorator 패턴들====		====Flyweight 패턴과 Proxy, Adapter, Decorator 패턴들====

Onionmixer: 메소드 > 메서드 수정

2013-01-08T11:02:33Z

메소드 > 메서드 수정

Show changes

Onionmixer: DPSC FLYWEIGHT 페이지 추가

2012-07-30T07:55:19Z

DPSC FLYWEIGHT 페이지 추가

Show changes

DesignPatternSmalltalkCompanion:Flyweight - Revision history

Onionmixer: 큰 따옴표

Onionmixer: 메소드 > 메서드 수정

Onionmixer: DPSC FLYWEIGHT 페이지 추가