SqueakByExample:6.3 - Revision history

Onionmixer: 번역수정

2013-09-17T02:38:50Z

번역수정

← Older revision		Revision as of 02:38, 17 September 2013
Line 62:		Line 62:


	~~여러분은~~ 또한 전체 패키지의 변경 세트(change set)를 얻기 위해 PackageInfo의 인스턴스에 ~~fileout을 발송할~~ 수 있습니다. 패키지들의 좀더 세련된 버전화를 위해, 우리는 몬티첼로(Monticello)를 사용합니다.		또한 전체 패키지의 변경 세트(change set)를 얻기 위해 PackageInfo의 인스턴스에 fileout 을 전송할 수 있습니다. 패키지들의 좀더 세련된 버전화를 위해, 우리는 몬티첼로(Monticello)를 사용합니다.


Line 99:		Line 99:
	그 다음 선택한 저장소에 대한 저장소 브라우저(repository browser)를 열기 위해 {{Template:HighlightBox\|Open}}을 클릭합니다. 그림 6.13과 같은 모습이 보일겁니다. 왼쪽은, 대상이 되는 저장소에 있는 모든 패키지의 목록이며, 만약 패키지중 하나를 선택하면, 오른쪽에 있는 패널에는 선택 패키지에 대한 이 저장소에 있는 모든 버전을 보여줍니다.		그 다음 선택한 저장소에 대한 저장소 브라우저(repository browser)를 열기 위해 {{Template:HighlightBox\|Open}}을 클릭합니다. 그림 6.13과 같은 모습이 보일겁니다. 왼쪽은, 대상이 되는 저장소에 있는 모든 패키지의 목록이며, 만약 패키지중 하나를 선택하면, 오른쪽에 있는 패널에는 선택 패키지에 대한 이 저장소에 있는 모든 버전을 보여줍니다.

	만약 ~~여러분이~~ 왼쪽목록에 나온 버전중 하나를 선택하면, 선택한 버전을(현재의 이미지에 로드하지 않고) {{Template:HighlightBox\|Browse}}(검색)하실 수 있으며, 현재의 이미지로 {{Template:HighlightBox\|Load}} 함으로써 ~~여러분의~~ 이미지에 발생한 {{Template:HighlightBox\|Changes}} 들을 볼 수 있습니다. 또한 패키지의 버전에 대한 {{Template:HighlightBox\|Copy}} 상태를 만들고, 다른 저장소에 저장할 수도 있습니다.		만약 왼쪽목록에 나온 버전중 하나를 선택하면, 선택한 버전을(현재의 이미지에 로드하지 않고) {{Template:HighlightBox\|Browse}}(검색)하실 수 있으며, 현재의 이미지로 {{Template:HighlightBox\|Load}} 함으로써 사용자의 이미지에 발생한 {{Template:HighlightBox\|Changes}} 들을 볼 수 있습니다. 또한 패키지의 버전에 대한 {{Template:HighlightBox\|Copy}} 상태를 만들고, 다른 저장소에 저장할 수도 있습니다.

	이렇듯이, 패키지의 이름을 포함하고 있는 버전의 이름은, 버전의 저자와 버전 번호의 머릿글자입니다. 버전 이름은 또한 저장소에 있는 파일 이름이기도 합니다. 이 이름들을 절대로 변경하시지 마세요. 몬티첼로의 수정 작업은 이 이름들을 기초로 진행됩니다. 몬티첼로 버전 파일들은 단지 Zip archives 입니다. 그리고 궁금하다는 이유로 zip 도구를 이용해서 파일 압축을 해제할 수 도 있지만, 파일의 내부를 살펴보는 제일 좋은 방법은 몬티첼로를 사용하는 것입니다.		이렇듯이, 패키지의 이름을 포함하고 있는 버전의 이름은, 버전의 저자와 버전 번호의 머릿글자입니다. 버전 이름은 또한 저장소에 있는 파일 이름이기도 합니다. 이 이름들을 절대로 변경하시지 마세요. 몬티첼로의 수정 작업은 이 이름들을 기초로 진행됩니다. 몬티첼로 버전 파일들은 단지 Zip archives 입니다. 그리고 궁금하다는 이유로 zip 도구를 이용해서 파일 압축을 해제할 수 도 있지만, 파일의 내부를 살펴보는 제일 좋은 방법은 몬티첼로를 사용하는 것입니다.
Line 135:		Line 135:


	물론, 당신은 SqueakSource에 있는 SqueakByExample 의저장소인 world저장소에 대해 읽기<sup>read</sup>는 가능하지만 , world저장소에 쓰기<sup>write</sup>는 불가능하기때문에, 만약 world저장소에 쓰기를 시도하고 저장하면, 반드시 에러메시지가 발생합니다. 그럼에도 불구하고, http://www.squeaksource.com 에 있는 웹 인터페이스<sup>the web interface</sup> 를 사용하여 사용자 자신만의 저장소를 만들 수 있으며, 당신의 작업을 저장하기 위해 이 웹 인터페이스를 사용할 수 있습니다. 이 웹 인터페이스는 특별히, 만약 여러 개의 컴퓨터를 사용하는 경우, 친구와 ~~여러분의~~ 코드를 공유하기 위한 메커니즘으로 매우 유용합니다. 만약 쓰기 권한을 갖고 있지 않은 저장소에 쓰기 및 저장을 시도해도, 서버에는 저장되지 않으며 저장하려는 버전은 package-cache에 기록됩니다.		물론, 당신은 SqueakSource에 있는 SqueakByExample 의저장소인 world저장소에 대해 읽기<sup>read</sup>는 가능하지만 , world저장소에 쓰기<sup>write</sup>는 불가능하기때문에, 만약 world저장소에 쓰기를 시도하고 저장하면, 반드시 에러메시지가 발생합니다. 그럼에도 불구하고, http://www.squeaksource.com 에 있는 웹 인터페이스<sup>the web interface</sup> 를 사용하여 사용자 자신만의 저장소를 만들 수 있으며, 당신의 작업을 저장하기 위해 이 웹 인터페이스를 사용할 수 있습니다. 이 웹 인터페이스는 특별히, 만약 여러 개의 컴퓨터를 사용하는 경우, 친구와 당신의 코드를 공유하기 위한 메커니즘으로 매우 유용합니다. 만약 쓰기 권한을 갖고 있지 않은 저장소에 쓰기 및 저장을 시도해도, 서버에는 저장되지 않으며 저장하려는 버전은 package-cache에 기록됩니다.

	[[image:MCaddToPackage.png\|none\|678px\|thumb\|그림 6.19: 패키지와 조합된 저장소들의 세트에 저장소 추가하기]]		[[image:MCaddToPackage.png\|none\|678px\|thumb\|그림 6.19: 패키지와 조합된 저장소들의 세트에 저장소 추가하기]]
Line 141:		Line 141:

	쓰기 권한이 없는경우 저장소에 저장을 할 수 없기때문에, 필요한경우 기존의 저장소 정보를 편집(몬티첼로 브라우저에서 노랑 버튼)하거나 또는 다른 저장소를 선택하고, 그 다음 패키지 캐쉬 브라우저(package-cache browser)로 부터 {{Template:HighlightBox\|Copy}}를 사용하여 내용을 복구(recover)하여야 합니다.		쓰기 권한이 없는경우 저장소에 저장을 할 수 없기때문에, 필요한경우 기존의 저장소 정보를 편집(몬티첼로 브라우저에서 노랑 버튼)하거나 또는 다른 저장소를 선택하고, 그 다음 패키지 캐쉬 브라우저(package-cache browser)로 부터 {{Template:HighlightBox\|Copy}}를 사용하여 내용을 복구(recover)하여야 합니다.

Onionmixer: 번역수정

2013-03-20T14:25:39Z

번역수정

← Older revision		Revision as of 14:25, 20 March 2013
Line 46:		Line 46:


	~~리펙토링~~ 브라우저 코드(the refactoring browser code)는 패키지의 이름으로서, RefactoringEngine 과 함께 패키지 작명 관례(package naming convetions)를 사용합니다. 워크스페이스에서, 아래의 구문으로 패키지의 모델을 만들어봅시다.		리팩토링 브라우저 코드(the refactoring browser code)는 패키지의 이름으로서, RefactoringEngine 과 함께 패키지 작명 관례(package naming convetions)를 사용합니다. 워크스페이스에서, 아래의 구문으로 패키지의 모델을 만들어봅시다.

	<syntaxhighlight lang="smalltalk">		<syntaxhighlight lang="smalltalk">
Line 54:		Line 54:


	이제 refactory 를 이용해서 패키지를 자세히 살펴보는(introspect) 작업이 가능해졌습니다. 예를 들면, refactory 클래스는 ~~리펙토링~~ 엔진(Refactoring Engine)과 ~~리펙토링~~ 브라우저(Refactoring Browser)를 만드는 긴 클래스의 목록을 반환할 것입니다. refactory coreMethods 는 그 클래스들에 있는 모든 메서드들을 위한 MethodReferences 목록을 반환할 것입니다. refactoryextensionMethods 는 아마도, 가장 흥미로운 질의중 하나일겁니다: refactoryextensionMethods는 RefactoringEngine에 포함되었지만 RefactoringEngine 클래스 내부에는 포함되지 않은, 모든 메서드들의 목록을 반환합니다. 예를 들어, 이 메서드들의 목록은 ClassDescription>>chooseThisClassInstVarThenDo: and SharedPool class>>keys 를 포함합니다.		이제 refactory 를 이용해서 패키지를 자세히 살펴보는(introspect) 작업이 가능해졌습니다. 예를 들면, refactory 클래스는 리팩토링 엔진(Refactoring Engine)과 리팩토링 브라우저(Refactoring Browser)를 만드는 긴 클래스의 목록을 반환할 것입니다. refactory coreMethods 는 그 클래스들에 있는 모든 메서드들을 위한 MethodReferences 목록을 반환할 것입니다. refactoryextensionMethods 는 아마도, 가장 흥미로운 질의중 하나일겁니다: refactoryextensionMethods는 RefactoringEngine에 포함되었지만 RefactoringEngine 클래스 내부에는 포함되지 않은, 모든 메서드들의 목록을 반환합니다. 예를 들어, 이 메서드들의 목록은 ClassDescription>>chooseThisClassInstVarThenDo: and SharedPool class>>keys 를 포함합니다.

	패키지 기능은 스퀵에 비교적 새롭게 추가된것이지만, 패키지 작명 관례(the package naming convettions)는 이미 사용되던 규칙을 기반으로 하기 때문에, 명확하지 않은 오래된 코드의 분석작업에 PackageInfo 를 사용할 수 있습니다.		패키지 기능은 스퀵에 비교적 새롭게 추가된것이지만, 패키지 작명 관례(the package naming convettions)는 이미 사용되던 규칙을 기반으로 하기 때문에, 명확하지 않은 오래된 코드의 분석작업에 PackageInfo 를 사용할 수 있습니다.

Onionmixer: 번역수정

2013-03-12T08:30:03Z

번역수정

← Older revision		Revision as of 08:30, 12 March 2013
Line 127:		Line 127:
	만약 패키지에 변경사항이 생겼다면(클래스 중의 하나에 메서드를 추가하라는등의 작업) (별표)는 패키지가 저장되지 않은 변경사항이 있다는 것을 알려주며 표가 다시 나타납니다. 만약 package-cache 에 있는 저장소 브라우저를 열면, 이미 저장되었던 버전을 선택할 수 있고 {{Template:HighlightBox\|Changes}} 들과 다른 버튼들을 사용할 수 있습니다. 물론 저장소에 새로운 버전을 저장할 수도 있습니다. 일단 저장소 뷰(the repository view)를 {{Template:HighlightBox\|Refresh}} 하셨다면, 그림 6.18과 같이 될것입니다.		만약 패키지에 변경사항이 생겼다면(클래스 중의 하나에 메서드를 추가하라는등의 작업) (별표)는 패키지가 저장되지 않은 변경사항이 있다는 것을 알려주며 표가 다시 나타납니다. 만약 package-cache 에 있는 저장소 브라우저를 열면, 이미 저장되었던 버전을 선택할 수 있고 {{Template:HighlightBox\|Changes}} 들과 다른 버튼들을 사용할 수 있습니다. 물론 저장소에 새로운 버전을 저장할 수도 있습니다. 일단 저장소 뷰(the repository view)를 {{Template:HighlightBox\|Refresh}} 하셨다면, 그림 6.18과 같이 될것입니다.

	[[image:package-cache-browser.png\|none\|450px\|thumb\|그림 6.18: 현재 ~~패키지 캐쉬에~~ 있는 ~~우리의~~ 패키지의 두 개의 버전]]		[[image:package-cache-browser.png\|none\|450px\|thumb\|그림 6.18: 현재 package-cache 에 있는 선택한 패키지의 두 개의 버전]]

Onionmixer: 번역수정

2013-03-12T08:29:20Z

번역수정

Show changes

Onionmixer: 번역수정

2013-03-12T06:21:57Z

번역수정

← Older revision		Revision as of 06:21, 12 March 2013
Line 10:		Line 10:


	예를 들어 설명해 보겠습니다. 스퀵에서 관계형 데이터 베이스를 사용하기위해 개발하고 있는 프레임 워크의 이름을 짓는다고 가정해 봅시다. 만들어지는 프레임워크를 SqueakLink라고 부르고, SqueakLink 프레임워크에 작성된 모든 클래스들을 포함하는 일련의 시스템 카테고리를 ~~만들었습니다~~.		예를 들어 설명해 보겠습니다. 스퀵에서 관계형 데이터 베이스를 사용하기위해 개발하고 있는 프레임 워크의 이름을 짓는다고 가정해 봅시다. 만들어지는 프레임워크를 SqueakLink라고 부르고, SqueakLink 프레임워크에 작성된 모든 클래스들을 포함하는 일련의 시스템 카테고리를 만들어 보겠습니다.

Onionmixer: 번역수정

2013-03-12T06:21:15Z

번역수정

← Older revision		Revision as of 06:21, 12 March 2013
Line 1:		Line 1:
	==몬티첼로(Monticello)==		==몬티첼로(Monticello)==

	2.9장 에서 스퀵의 패키징 도구인 몬티첼로에 대해 간단하게 알아봤습니다. 하지만, 몬티첼로에는 알려드린 내용보다 더 많은 기능이 있습니다. 몬티첼로가 패키지를 관리하기 ~~때문이며,~~ 이 ~~장에서는~~ 몬티첼로에 관해 말씀드리기 전에, ~~중요한 내용으로서 패키지가~~ 정확히 무엇인지 부터 설명하도록 하겠습니다.		2.9장 에서 스퀵의 패키징 도구인 몬티첼로에 대해 간단하게 알아봤습니다. 하지만, 몬티첼로에는 알려드린 내용보다 더 많은 기능이 있습니다. 이는 몬티첼로가 패키지를 관리하기 때문입니다. 그렇지만 이 장 에서는 몬티첼로에 관해 말씀드리기 전에 알아야할 중요한 내용인, 패키지는 정확히 무엇인지 부터 설명하도록 하겠습니다.

Onionmixer: 번역수정

2013-03-12T06:19:39Z

번역수정

← Older revision		Revision as of 06:19, 12 March 2013
Line 1:		Line 1:
	==몬티첼로(Monticello)==		==몬티첼로(Monticello)==

	~~우리는 섹션~~ 2.~~9에서~~ 스퀵의 패키징 도구인 ~~몬티첼로의 짧은 개관을 제공해드렸습니다~~. ~~그럼에도 불구하고~~, ~~몬티첼로는 제공해 드린~~ 내용보다 더 많은 ~~기능들을 갖고~~ 있습니다. ~~그 이유는~~ 몬티첼로가 패키지를 관리하기 때문이며, ~~여기서는 여러분에게~~ 몬티첼로에 관해 말씀드리기 전에, 패키지가 정확히 무엇인지 ~~설명 드리는 것이 중요하다고 생각합니다~~.		2.9장 에서 스퀵의 패키징 도구인 몬티첼로에 대해 간단하게 알아봤습니다. 하지만, 몬티첼로에는 알려드린 내용보다 더 많은 기능이 있습니다. 몬티첼로가 패키지를 관리하기 때문이며, 이 장에서는 몬티첼로에 관해 말씀드리기 전에, 중요한 내용으로서 패키지가 정확히 무엇인지 부터 설명하도록 하겠습니다.



	===패키지:스퀵 코드의 ~~서술적 범주화~~(declarative categorization)===		===패키지:스퀵 코드의 선언적 분류(declarative categorization)===

	패키지 시스템은 단순하며, 스몰토크 소스 ~~코드를 조직하는 가벼운~~ 방법입니다. 이 시스템은 섹션 6.~~2에서 언급된 오래 사용된 작명 관례를(naming convention) 레버레지(leverage)하지만, 중요한 방식으로 그 관례를 추가합니다~~.		패키지 시스템은 단순하며, 스몰토크 소스 코드의 체계를 구성하는 가볍고 간략한 방법입니다. 패키지 시스템은 덧붙여 6.2장 에서 살펴본 '''오래된 작명관례''' 라고 불리는 방법을 사용합니다..

	예를 들어 이 내용을 설명 드리겠습니다. 여러분이 스퀵으로부터 관계형 데이터 베이스의 사용을 촉진하기 위해 작명된 프레임 워크를 개발하고 있다고 가정해 봅시다. 여러분은 여러분의 프레임워크를 SqueakLink로 부르고, 여러분이 작성한 모든 클래스들을 포함하도록 일련의 시스템 카테고리를 만들었습니다

			예를 들어 설명해 보겠습니다. 스퀵에서 관계형 데이터 베이스를 사용하기위해 개발하고 있는 프레임 워크의 이름을 짓는다고 가정해 봅시다. 만들어지는 프레임워크를 SqueakLink라고 부르고, SqueakLink 프레임워크에 작성된 모든 클래스들을 포함하는 일련의 시스템 카테고리를 만들었습니다.

	'''Category 'SqueakLink--Connections' contains OracleConnection MySQLConnection PostgresConnection'''<br>
	'''Category 'SqueakLink--Model' contains DBTable DBRow DBQuery'''		'''Category 'SqueakLink-Connections' contains OracleConnection MySQLConnection PostgresConnection'''<br>
			'''Category 'SqueakLink-Model' contains DBTable DBRow DBQuery'''


	~~그럼에도 불구하고, 여러분의 코드가 이 클래스들에 모두 상주될 것은~~ 아닙니다. 예를 들면, ~~여러분은~~ SQL~~-Friendly 포맷으로~~ 오브젝트를 ~~변환하는 메서드들의 시리즈들을 얻어야 할 것입니다~~.		위에서 보이는것처럼 여러개의 카테고리와 클래스등등이 만들어지겠죠. 하지만 저 클래스들 모두에 일일히 코드를 넣어줘야 하는건 아닙니다. 예를 들자면, SQL 친화적인 상태로 오브젝트를 변환해주는 메소드 등이 있을 수 있습니다..


	<syntaxhighlight lang="text">		<syntaxhighlight lang="text">
	~~Object»asSQL~~		Object>>asSQL
	~~String»asSQL~~		String>>asSQL
	~~Date»asSQL~~		Date>>asSQL
	</syntaxhighlight>		</syntaxhighlight>

Line 30:		Line 32:

	Foo로 작명된 패키지는 다음을 포함합니다:		Foo로 작명된 패키지는 다음을 포함합니다:


	# 카테고리 Foo 또는 Foo로 시작하는 이름들에 있는 모든 클래스의 정의		# 카테고리 Foo 또는 Foo로 시작하는 이름들에 있는 모든 클래스의 정의

Onionmixer at 04:50, 30 August 2012

2012-08-30T04:50:11Z

Onionmixer: SBE 몬티첼로 페이지 추가

2012-08-14T13:22:47Z

SBE 몬티첼로 페이지 추가

New page

==몬티첼로(Monticello)==

우리는 섹션 2.9에서 스퀵의 패키징 도구인 몬티첼로의 짧은 개관을 제공해드렸습니다. 그럼에도 불구하고, 몬티첼로는 제공해 드린 내용보다 더 많은 기능들을 갖고 있습니다. 그 이유는 몬티첼로가 패키지를 관리하기 때문이며, 여기서는 여러분에게 몬티첼로에 관해 말씀드리기 전에, 패키지가 정확히 무엇인지 설명 드리는 것이 중요하다고 생각합니다.

===패키지:스퀵 코드의 서술적 범주화(declarative categorization)===

패키지 시스템은 단순하며, 스몰토크 소스 코드를 조직하는 가벼운 방법입니다. 이 시스템은 섹션 6.2에서 언급된 오래 사용된 작명 관례를(naming convention) 레버레지(leverage)하지만, 중요한 방식으로 그 관례를 추가합니다.

예를 들어 이 내용을 설명 드리겠습니다. 여러분이 스퀵으로부터 관계형 데이터 베이스의 사용을 촉진하기 위해 작명된 프레임 워크를 개발하고 있다고 가정해 봅시다. 여러분은 여러분의 프레임워크를 SqueakLink로 부르고, 여러분이 작성한 모든 클래스들을 포함하도록 일련의 시스템 카테고리를 만들었습니다

'''Category 'SqueakLink--Connections' contains OracleConnection MySQLConnection PostgresConnection'''<br>
'''Category 'SqueakLink--Model' contains DBTable DBRow DBQuery'''

그럼에도 불구하고, 여러분의 코드가 이 클래스들에 모두 상주될 것은 아닙니다. 예를 들면, 여러분은 SQL-Friendly 포맷으로 오브젝트를 변환하는 메소드들의 시리즈들을 얻어야 할 것입니다.

<syntaxhighlight lang="text">
Object»asSQL
String»asSQL
Date»asSQL
</syntaxhighlight>

이 메소드들은 카테고리 '''SqueakLink-Connections''' 와 '''SqueakLink—Model'''에 있는 클래스들과 동일한 패키지에 속해 있습니다. 그러나 분명한 것은 전체 클래스 오브젝트는 여러분의 패키지에 속해 있지 않습니다! 그러므로, 비록 다른 패키지에 클래스의 나머지가 남아 있을 지라도, 특정한 메소드들을 패키지에 넣어야 합니다.

이 방법을 여러분이 수행하려면 '''''*squeaklink'''''로 작명된 (초기 별표와 소문자 이름에 주의합니다) 프로토콜(오브젝트, 문자열, 날짜 등)에 메소드들을 배치하여야 합니다. '''SqueakLink'''의 조합은-…카테고리들 그리고 '''''*squeaklink''''' 프로토콜은 '''SqueakLink'''로 작명된 패키지를 형성합니다. 좀 더 정확히 말씀드리자면, 패키지에 발생하는 작업에 대한 규칙은 다음과 같습니다.

Foo로 작명된 패키지는 다음을 포함합니다:

# 카테고리 Foo 또는 Foo로 시작하는 이름들에 있는 모든 클래스의 정의
# *foo로 작명된 프로토콜에 있는 모든 클래스 속의 모든 메소드 정의들 또는 *foo-로 시작하는 이름들 (이 이름 비교를 할 때, 이름에 있는 글자들의 대소문자는 무시됩니다)
# 카테고리 Foo 속에 있는 모든 메소드들 또는 Foo-로 시작하는 이름으로 시작하는 모든 메소드들, *로 시작하는 이름을 가진 프로토콜 속에 있는 메소드들은 제외

이 규칙들의 결과로, 각 클래스 정의와 각 메소스들의 정의는 정확히 하나의 패키지에 속하게 됩니다. 마지막 규칙에서의 예외는 반드시 시행되어야 하며, 그 이유는 그 메소드들이 반드시 다른 패키지에 소속되어야 하기 때문입니다. 규칙 2에서 대소문자 구별을 무시하는 이유는, 관례적으로 카테고리 이름들이 CamelCase(그리고 스페이스를 포함하지 않음)를 사용하는 반면, 프로토콜 이름들은 (스페이스를 포함할 수 있음) 모두 소문자 이기 때문입니다.

클래스 PackageInfo는 이러한 규칙들을 사용하며, 이 규칙들에 대한 감각을 익히는 방법은 이 클래스로 실행하는 것입니다.

{{CommentSqueak|이 작업을 여러분의 이미지에 시도하면, 클래스 PackageInfo와 RefactoringBrowser를 포함하여야 합니다.}}

리펙토링 브라우저 코드(the refactoring browser code)는 패키지 이름으로서, RefactoringEnging과 함께 패키지 작명 관례(package naming convetions)를 사용합니다. 워크스페이스에서, refactory := PackageInfo named: 'RefactoringEngine'와 함께 이 패키지의 모델을 만듭니다.

<syntaxhighlight lang="smalltalk">
refactory := PackageInfo named: 'RefactoringEngine'.
</syntaxhighlight>

이제 이 패키지를 자세히 살피는 작업이(introspect) 가능합니다. 예를 들면, refactory 클래스는 리펙토링 엔진(Refactoring Engine)과 리펙토링 브라우저(Refactoring Browser)를 만드는 긴 클래스의 목록을 리턴할 것입니다. refactory coreMethods 는 그 클래스들에 있는 모든 메소드들을 위한 MethodReferences 목록을 리턴할 것입니다. refactoryextensionMethods 는 아마도, 가장 흥미로운 쿼리들 중의 하나일 것입니다: 이것은 RefactoringEngine에 포함되었지만 RefactoringEngine 클래스 내부에는 포함되지 않은, 모든 메소드들의 목록을 리턴 할 것입니다. 이 목록은 예를 들어, ClassDescription»chooseThisClassInstVarThenDo: and SharedPool class»keys 를 포함할 것입니다.

패키지들은 스퀵에 비교적 새로운 추가물 이지만, 패키지 작명 관례(the package naming convettions)가 이미 사용중인 것들에 기초하였었기 때문에,코드로 작업을 하기 위해 명백하게 채택되지 않은 옛코드를 분석하기 위한 목적으로 PackageInfor 사용도 가능합니다.

{{CommentSqueak|{{Template:HighlightBold|(PackageInfo named: 'Collections') externalSubclasses}}를 평가합니다, 이 표현식은 {{Template:HighlightBold|Collections}} 패키지에 없는 Collection 의 모든 서브클래스들의 목록을 답으로 내놓을 것입니다.}}

여러분은 또한 전체 패키지의 변경 세트(change set)를 얻기 위해 PackageInfo의 인스턴스에 fileout을 발송할 수 있습니다. 패키지들의 좀더 세련된 버전화를 위해, 우리는 몬티첼로(Monticello)를 사용합니다.

===몬티첼로 기본사항(Basic Monticello)===

몬티첼로는 미국의 3 번째 대통령 토머스 제퍼슨의 산 꼭대기 집과(the mountaintop home)과 종교의 자유를 위한 버지니아의 법령의 저자의 이름을 본 딴 것입니다. 이 이름이 의미하는 것은 이탈리아어로 “작은 산” 이며, 그러므로, 항상 이탈리어로 “c” 로 발음되며, 이 음절은 chiair:Mont-y’-che-llo 에서 “ch” 와 같습니다.

[[image:freshMonticello.png|none|589px|thumb|그림 6.12: 몬티첼로 브라우저(Monticello browser)]]

그림 6.12에서 보이는 것 처럼, 여러분이 몬티첼로 브라우저를 열 때, 두 개의 목록 패널들을 볼 수 있으며, 버튼들의 열을 볼 수 있습니다. 왼쪽의 패널은 여러분이 실행하고 있는 이미지에 로드된 패키지들의 모든 것들을 열거하였으며 패키지의 특별한 버전은 이름 뒤 괄호에 보입니다.

오른쪽의 패널은 몬티첼로가 알고 있는 모든 소스코드 저장소들을 열거하며, 그 이유는 보통, 그 저장소들로부터 코드를 로드 하였기 때문입니다.
만약 여러분이 왼쪽 패널에서 패키지를 선택하셨다면, 오른쪽 패널은 오직 선택된 패키지의 버전을 포함하고 있는 저장소들만을 보여드리기 위해 필터링 되었을 것입니다.

디렉토리에 있는 저장소들 중의 하나는 패키지 캐쉬라고 지명된 디렉토리이며, 이것은 여러분의 이미지가 실행중인 디렉토리의 서브 디렉토리입니다. 여러분이 원격 저장소(remote repository)로부터 코드를 로드 하시거나 작성하실 때, 복사본이 패키지 캐쉬에 저장되며, 이것은 만약 네트워크가 사용 가능하지 않을 때 유용하며, 여러분은 또한 패키지에 접근할 필요가 있습니다. 또한, 만약 여러분이 예를 들어 이메일 첨부파일로 직접 몬티첼로(.mcz) 파일을 받으셨다면, 그 파일에 접근하기 위한 가장 편리한 방법은 패키지-캐쉬 디렉토리에 배치하는 것입니다.

목록에 새로운 저장소를 더하려면 {{Template:HighlightBox|+Repository}} 를 클릭하고, 팝업 메뉴에서 저장소의 종류를 선택합니다. {{Template:HighlightGray|HTTP}} 저장소를 더해봅시다.

{{CommentSqueak|몬티첼로를 열고 {{Template:HighlightBox|+Repository}} 버튼을 누르고 {{Template:HighlightGray|HTTP}}를 선택합니다. Dialog를 읽고 편집합니다.}}

[[image:SqueakSource-SBE.png|none|466px|thumb|그림 6.13:저장소 브라우저(A Repository browser)]]

<syntaxhighlight lang="smalltalk">
MCHttpRepository
location: 'http://squeaksource.com/SqueakByExample'
user: ''
password: ''
</syntaxhighlight>

그 다음 이 저장소에서 저장소 브라우저(repository browser)를 열기 위해 {{Template:HighlightBox|Open}}을 클릭합니다. 여러분이 그림 6.13과 같은 모습을 보실 수 있어야만 합니다. 왼쪽온, 저장소에 있는 모든 패키지의 목록이며, 만약 여러분이 하나를 선택하면, 오른쪽에 있는 패널은 이 저장소에 있는 선택된 패키지의 모든 버전을 보여드릴 것입니다.

만약 여러분이 버전들 하나를 선택하면, 그 버전을 {{Template:HighlightBox|Browse(검색)}}하실 수 있으며(여러분의 이미지에 로드하지 않고), 그것을 {{Template:HighlightBox|Load}} 할 수 있거나 또는 선택된 버전을 로드함으로써 여러분의 이미지에 가한 {{Template:HighlightBox|Changes}} 들을 볼 수 있습니다. 여러분은 또한 패키지의 버전의 {{Template:HighlightBox|Copy}} 본을 만들어, 다른 저장소에 쓰기를 할 수 있습니다.

여러분이 보실 수 있듯이, 패키지의 이름을 포함하고 있는 버전들의 이름은, 버전의 저자와 버전 번호의 이니셜입니다. 버전 이름은 또한 저장소에 있는 파일 이름입니다. 이 이름들을 절대로 변경하시지 마십시오. 몬티첼로의 수정 작업은 이 이름들에 기초해 있습니다. 몬티첼로 버전 파일들은 단지 Zip archives 이므로, 마약 여러분이 zip 도구로 이 파일 압축을 해제하여 파일의 항목들을 보는 방법이 궁금하시다면, 가장 최상의 방법은 몬티첼로 자체를 사용하는 것입니다.

몬티첼로로 패키지를 만들려면, 두 가지 작업을 하셔야 합니다: 몇 가지 코드를 쓰고 몬티첼로에게 그것에 관해 말하셔야 합니다.

[[image:MCnewcategory.png|none|527px|thumb|그림 6.14 “SBE” 패키지들에 있는 두 개의 클래스들]]

{{CommentSqueak|{{Template:HighlightBold|SBE-Monticello}} 라 불리는 카테고리를 만들고, 몇 개의 클래스를 그림 6.14에서 보이는 것 처럼, 집어넣습니다. 또한 현존하는 클래스에 메소드를 만들고, 그림 6.15에서 보이는 것 처럼 규칙들을 사용하여 여러분의 클래스들과 동일한 패키지에 그 메소드를 집어 넣습니다- 그림 6.15를 보십시오.}}

몬티첼로에게 여러분의 패키지에 관해 말하려면, {{Template:HighlightBox|+Package}} 를 클릭하고, 패키지의 이름을 타이핑 합니다. 이번 경우는 “SBE”입니다. 몬티첼로는 SBE를 그 자체의 패키지의 목록에 더할 것입니다. 패키지 엔트리는 이미지에 있는 버전이 어떤 저장소에도 기록되지 않았다는 것을 보여드리기 위해 *(별표)로 표시될 것입니다.

초기에는, 그림 6.16에서 보이는 것 처럼, 이 패키지와 관련된 저장소만이 여러분의 패키지 캐쉬에 있게 될 것입니다. 그것은 괜찮습니다: 여러분은 여전히 코드를 저장할 수 있으며, 그 작업은 코드가 패키지 캐쉬에 기록되도록 할 것입니다. {{Template:HighlightBox|Save}}를 클릭하면, 그림 6.17에서 보이는 것처럼 조금 후 저장할 패키지의 버전을 위한 로그 메시지를 제공을 권유 받을 것입니다. 여러분이 이 메시지를 수락하면, 몬티첼로는 패키지를 저장할 것입니다. 이 작업을 가리키기 위해 몬티첼로 패키지 패널에 있는 이름을 꾸미는 별표가 제거될 것이며 버전이 추가될 것입니다.

만약 패키지에 변경사항을 만드셨다면(클래스 중의 하나에 메소드를 추가하라고 말함으로써)별표는 여러분이 저장되지 않은 변경사항들을 갖고 있다는 것을 보여드리며 다시 나타날 것입니다. 만약 여러분이 패키지 캐쉬에 있는 저장소 브라우저를 열면, 저장된 버전을 선택할 수 있고 {{Template:HighlightBox|Changes}} 들과 다른 버튼들을 사용할 수 있습니다. 여러분은 물론 저장소에 새로운 버전을 저장할 수 있습니다. 일단 저장소 뷰(the repository view)를 {{Template:HighlightBox|Refresh}} 하셨다면, 그림 6.18과 같이 되어야만 합니다.

패키지 캐쉬기 아닌 저장소에 새로운 패키지를 더하시려면, 필요한 경우 추가하여, 먼저 몬티첼로가 저장소에 관하여 알도록 만들어야만 합니다.

[[image:MCnewmethod.png|none|565px|thumb|그림 6.15: “SBE” 패키지에 있게 될 확장 메소드(extension method)]]

[[image:MC+SBE.png|none|678px|thumb|그림 6.16: 몬티첼로에 있는 아직까지 저장되지 않은 SBE 패키지]]

그 다음 패키지 캐쉬 저장소 브라우저에 있는 {{Template:HighlightBox|Copy}} 를 사용하실 수 있으며, 패키지가 복사되어야만 될 저장소를 선택하실 수 있습니다. 또한 그림 6.19에 보이는 것처럼 노랑버튼 메뉴 아이템 add to package 를 사용하여 패키지와 원하는 저장소를 조합시킬 수 있습니다. 일단 패키지가 저장소에 관하여 알게 되면, 여러분은 몬티첼로 브라우저에 저장소와 패키지를 선택하고 {{Template:HighlightBox|Save}} 를 클릭하여 새로운 버전을 저장할 수 있습니다.

[[image:SBE-apb.png|none|394px|thumb|그림 6.17: 패키지의 새로운 버전을 위한 로그 메시지 제공하기]]

[[image:package-cache-browser.png|none|450px|thumb|그림 6.18: 현재 패키지 캐쉬에 있는 우리의 패키지의 두 개의 버전]]

물론, 여러분은 SqueakSource에 있는 SqueakByExample 저장소는 world 읽기 가능하지만, world 쓰기는 가능하지 않으므로, 만약 이곳에서 쓰기를 시도하고 저장하면, 반드시 에러메시지를 보시게 될 것입니다. 그럼에도 불구하고, http://www.squeaksource.com에 있는 웹 인터페이스 (the web interface)를 사용하여 여러분 자신만의 저장소를 만들 수 있으며, 여러분의 작업을 저장하기 위해 이 웹 인터페이스를 사용할 수 있습니다. 이 웹 인터페이스는 특별히, 만약 여러 개의 컴퓨터를 사용한다면, 친구와 여러분의 코드를 공유하기 위한 메커니즘으로 매우 유용합니다.
만약 여러분이 쓰기 허락을 갖고 있지 않은 저장소에 쓰기를 시도하고 저장을 시도하셨다면, 그럼에도 불구하고 버전은 패키지 캐쉬에 기록될 것입니다.

[[image:MCaddToPackage.png|none|678px|thumb|그림 6.19: 패키지와 조합된 저장소들의 세트에 저장소 추가하기]]

그러므로, 여러분은 저장소 정보를 편집(몬티첼로 브라우저에서 노랑 버튼)하거나 또는 다른 저장소를 선택하고, 그 다음 패키지 캐쉬 브라우저(package-cache browser)로 부터 {{Template:HighlightBox|Copy}}를 사용하여 복구(recover)할 수 있습니다.

==Notes==
<references />

[[Category:SqueakByExample]]

← Older revision		Revision as of 04:50, 30 August 2012
Line 14:		Line 14:


	그럼에도 불구하고, 여러분의 코드가 이 클래스들에 모두 상주될 것은 아닙니다. 예를 들면, 여러분은 SQL-Friendly 포맷으로 오브젝트를 변환하는 ~~메소드들의~~ 시리즈들을 얻어야 할 것입니다.		그럼에도 불구하고, 여러분의 코드가 이 클래스들에 모두 상주될 것은 아닙니다. 예를 들면, 여러분은 SQL-Friendly 포맷으로 오브젝트를 변환하는 메서드들의 시리즈들을 얻어야 할 것입니다.


Line 24:		Line 24:


	이 ~~메소드들은~~ 카테고리 '''SqueakLink-Connections''' 와 '''SqueakLink—Model'''에 있는 클래스들과 동일한 패키지에 속해 있습니다. 그러나 분명한 것은 전체 클래스 오브젝트는 여러분의 패키지에 속해 있지 않습니다! 그러므로, 비록 다른 패키지에 클래스의 나머지가 남아 있을 지라도, 특정한 ~~메소드들을~~ 패키지에 넣어야 합니다.		이 메서드들은 카테고리 '''SqueakLink-Connections''' 와 '''SqueakLink—Model'''에 있는 클래스들과 동일한 패키지에 속해 있습니다. 그러나 분명한 것은 전체 클래스 오브젝트는 여러분의 패키지에 속해 있지 않습니다! 그러므로, 비록 다른 패키지에 클래스의 나머지가 남아 있을 지라도, 특정한 메서드들을 패키지에 넣어야 합니다.

	이 방법을 여러분이 수행하려면 '''''squeaklink'''''로 작명된 (초기 별표와 소문자 이름에 주의합니다) 프로토콜(오브젝트, 문자열, 날짜 등)에 ~~메소드들을~~ 배치하여야 합니다. '''SqueakLink'''의 조합은-…카테고리들 그리고 '''''squeaklink''''' 프로토콜은 '''SqueakLink'''로 작명된 패키지를 형성합니다. 좀 더 정확히 말씀드리자면, 패키지에 발생하는 작업에 대한 규칙은 다음과 같습니다.		이 방법을 여러분이 수행하려면 '''''squeaklink'''''로 작명된 (초기 별표와 소문자 이름에 주의합니다) 프로토콜(오브젝트, 문자열, 날짜 등)에 메서드들을 배치하여야 합니다. '''SqueakLink'''의 조합은-…카테고리들 그리고 '''''squeaklink''''' 프로토콜은 '''SqueakLink'''로 작명된 패키지를 형성합니다. 좀 더 정확히 말씀드리자면, 패키지에 발생하는 작업에 대한 규칙은 다음과 같습니다.


Line 33:		Line 33:

	# 카테고리 Foo 또는 Foo로 시작하는 이름들에 있는 모든 클래스의 정의		# 카테고리 Foo 또는 Foo로 시작하는 이름들에 있는 모든 클래스의 정의
	# foo로 작명된 프로토콜에 있는 모든 클래스 속의 모든 ~~메소드~~ 정의들 또는 foo-로 시작하는 이름들 (이 이름 비교를 할 때, 이름에 있는 글자들의 대소문자는 무시됩니다)		# foo로 작명된 프로토콜에 있는 모든 클래스 속의 모든 메서드 정의들 또는 foo-로 시작하는 이름들 (이 이름 비교를 할 때, 이름에 있는 글자들의 대소문자는 무시됩니다)
	# 카테고리 Foo 속에 있는 모든 ~~메소드들~~ 또는 Foo-로 시작하는 이름으로 시작하는 모든 ~~메소드들~~, *로 시작하는 이름을 가진 프로토콜 속에 있는 ~~메소드들은~~ 제외		# 카테고리 Foo 속에 있는 모든 메서드들 또는 Foo-로 시작하는 이름으로 시작하는 모든 메서드들, *로 시작하는 이름을 가진 프로토콜 속에 있는 메서드들은 제외


	이 규칙들의 결과로, 각 클래스 정의와 각 메소스들의 정의는 정확히 하나의 패키지에 속하게 됩니다. 마지막 규칙에서의 예외는 반드시 시행되어야 하며, 그 이유는 그 ~~메소드들이~~ 반드시 다른 패키지에 소속되어야 하기 때문입니다. 규칙 2에서 대소문자 구별을 무시하는 이유는, 관례적으로 카테고리 이름들이 CamelCase(그리고 스페이스를 포함하지 않음)를 사용하는 반면, 프로토콜 이름들은 (스페이스를 포함할 수 있음) 모두 소문자 이기 때문입니다.		이 규칙들의 결과로, 각 클래스 정의와 각 메소스들의 정의는 정확히 하나의 패키지에 속하게 됩니다. 마지막 규칙에서의 예외는 반드시 시행되어야 하며, 그 이유는 그 메서드들이 반드시 다른 패키지에 소속되어야 하기 때문입니다. 규칙 2에서 대소문자 구별을 무시하는 이유는, 관례적으로 카테고리 이름들이 CamelCase(그리고 스페이스를 포함하지 않음)를 사용하는 반면, 프로토콜 이름들은 (스페이스를 포함할 수 있음) 모두 소문자 이기 때문입니다.

	클래스 PackageInfo는 이러한 규칙들을 사용하며, 이 규칙들에 대한 감각을 익히는 방법은 이 클래스로 실행하는 것입니다.		클래스 PackageInfo는 이러한 규칙들을 사용하며, 이 규칙들에 대한 감각을 익히는 방법은 이 클래스로 실행하는 것입니다.
Line 53:		Line 53:


	이제 이 패키지를 자세히 살피는 작업이(introspect) 가능합니다. 예를 들면, refactory 클래스는 리펙토링 엔진(Refactoring Engine)과 리펙토링 브라우저(Refactoring Browser)를 만드는 긴 클래스의 목록을 리턴할 것입니다. refactory coreMethods 는 그 클래스들에 있는 모든 ~~메소드들을~~ 위한 MethodReferences 목록을 리턴할 것입니다. refactoryextensionMethods 는 아마도, 가장 흥미로운 쿼리들 중의 하나일 것입니다: 이것은 RefactoringEngine에 포함되었지만 RefactoringEngine 클래스 내부에는 포함되지 않은, 모든 ~~메소드들의~~ 목록을 리턴 할 것입니다. 이 목록은 예를 들어, ClassDescription»chooseThisClassInstVarThenDo: and SharedPool class»keys 를 포함할 것입니다.		이제 이 패키지를 자세히 살피는 작업이(introspect) 가능합니다. 예를 들면, refactory 클래스는 리펙토링 엔진(Refactoring Engine)과 리펙토링 브라우저(Refactoring Browser)를 만드는 긴 클래스의 목록을 리턴할 것입니다. refactory coreMethods 는 그 클래스들에 있는 모든 메서드들을 위한 MethodReferences 목록을 리턴할 것입니다. refactoryextensionMethods 는 아마도, 가장 흥미로운 쿼리들 중의 하나일 것입니다: 이것은 RefactoringEngine에 포함되었지만 RefactoringEngine 클래스 내부에는 포함되지 않은, 모든 메서드들의 목록을 리턴 할 것입니다. 이 목록은 예를 들어, ClassDescription»chooseThisClassInstVarThenDo: and SharedPool class»keys 를 포함할 것입니다.

	패키지들은 스퀵에 비교적 새로운 추가물 이지만, 패키지 작명 관례(the package naming convettions)가 이미 사용중인 것들에 기초하였었기 때문에,코드로 작업을 하기 위해 명백하게 채택되지 않은 옛코드를 분석하기 위한 목적으로 PackageInfor 사용도 가능합니다.		패키지들은 스퀵에 비교적 새로운 추가물 이지만, 패키지 작명 관례(the package naming convettions)가 이미 사용중인 것들에 기초하였었기 때문에,코드로 작업을 하기 위해 명백하게 채택되지 않은 옛코드를 분석하기 위한 목적으로 PackageInfor 사용도 가능합니다.
Line 105:		Line 105:


	[[image:MCnewcategory.png\|none\|527px\|thumb\|그림 6.14 ~~“SBE”~~ 패키지들에 있는 두 개의 클래스들]]		[[image:MCnewcategory.png\|none\|527px\|thumb\|그림 6.14 "SBE" 패키지들에 있는 두 개의 클래스들]]


	{{CommentSqueak\|{{Template:HighlightBold\|SBE-Monticello}} 라 불리는 카테고리를 만들고, 몇 개의 클래스를 그림 6.14에서 보이는 것 처럼, 집어넣습니다. 또한 현존하는 클래스에 ~~메소드를~~ 만들고, 그림 6.15에서 보이는 것 처럼 규칙들을 사용하여 여러분의 클래스들과 동일한 패키지에 그 ~~메소드를~~ 집어 넣습니다- 그림 6.15를 보십시오.}}		{{CommentSqueak\|{{Template:HighlightBold\|SBE-Monticello}} 라 불리는 카테고리를 만들고, 몇 개의 클래스를 그림 6.14에서 보이는 것 처럼, 집어넣습니다. 또한 현존하는 클래스에 메서드를 만들고, 그림 6.15에서 보이는 것 처럼 규칙들을 사용하여 여러분의 클래스들과 동일한 패키지에 그 메서드를 집어 넣습니다- 그림 6.15를 보십시오.}}


Line 115:		Line 115:
	초기에는, 그림 6.16에서 보이는 것 처럼, 이 패키지와 관련된 저장소만이 여러분의 패키지 캐쉬에 있게 될 것입니다. 그것은 괜찮습니다: 여러분은 여전히 코드를 저장할 수 있으며, 그 작업은 코드가 패키지 캐쉬에 기록되도록 할 것입니다. {{Template:HighlightBox\|Save}}를 클릭하면, 그림 6.17에서 보이는 것처럼 조금 후 저장할 패키지의 버전을 위한 로그 메시지를 제공을 권유 받을 것입니다. 여러분이 이 메시지를 수락하면, 몬티첼로는 패키지를 저장할 것입니다. 이 작업을 가리키기 위해 몬티첼로 패키지 패널에 있는 이름을 꾸미는 별표가 제거될 것이며 버전이 추가될 것입니다.		초기에는, 그림 6.16에서 보이는 것 처럼, 이 패키지와 관련된 저장소만이 여러분의 패키지 캐쉬에 있게 될 것입니다. 그것은 괜찮습니다: 여러분은 여전히 코드를 저장할 수 있으며, 그 작업은 코드가 패키지 캐쉬에 기록되도록 할 것입니다. {{Template:HighlightBox\|Save}}를 클릭하면, 그림 6.17에서 보이는 것처럼 조금 후 저장할 패키지의 버전을 위한 로그 메시지를 제공을 권유 받을 것입니다. 여러분이 이 메시지를 수락하면, 몬티첼로는 패키지를 저장할 것입니다. 이 작업을 가리키기 위해 몬티첼로 패키지 패널에 있는 이름을 꾸미는 별표가 제거될 것이며 버전이 추가될 것입니다.

	만약 패키지에 변경사항을 만드셨다면(클래스 중의 하나에 ~~메소드를~~ 추가하라고 말함으로써)별표는 여러분이 저장되지 않은 변경사항들을 갖고 있다는 것을 보여드리며 다시 나타날 것입니다. 만약 여러분이 패키지 캐쉬에 있는 저장소 브라우저를 열면, 저장된 버전을 선택할 수 있고 {{Template:HighlightBox\|Changes}} 들과 다른 버튼들을 사용할 수 있습니다. 여러분은 물론 저장소에 새로운 버전을 저장할 수 있습니다. 일단 저장소 뷰(the repository view)를 {{Template:HighlightBox\|Refresh}} 하셨다면, 그림 6.18과 같이 되어야만 합니다.		만약 패키지에 변경사항을 만드셨다면(클래스 중의 하나에 메서드를 추가하라고 말함으로써)별표는 여러분이 저장되지 않은 변경사항들을 갖고 있다는 것을 보여드리며 다시 나타날 것입니다. 만약 여러분이 패키지 캐쉬에 있는 저장소 브라우저를 열면, 저장된 버전을 선택할 수 있고 {{Template:HighlightBox\|Changes}} 들과 다른 버튼들을 사용할 수 있습니다. 여러분은 물론 저장소에 새로운 버전을 저장할 수 있습니다. 일단 저장소 뷰(the repository view)를 {{Template:HighlightBox\|Refresh}} 하셨다면, 그림 6.18과 같이 되어야만 합니다.

	패키지 캐쉬기 아닌 저장소에 새로운 패키지를 더하시려면, 필요한 경우 추가하여, 먼저 몬티첼로가 저장소에 관하여 알도록 만들어야만 합니다.		패키지 캐쉬기 아닌 저장소에 새로운 패키지를 더하시려면, 필요한 경우 추가하여, 먼저 몬티첼로가 저장소에 관하여 알도록 만들어야만 합니다.


	[[image:MCnewmethod.png\|none\|565px\|thumb\|그림 6.15: ~~“SBE”~~ 패키지에 있게 될 확장 ~~메소드~~(extension method)]]		[[image:MCnewmethod.png\|none\|565px\|thumb\|그림 6.15: "SBE" 패키지에 있게 될 확장 메서드(extension method)]]