OSXDEV.ORG
Mac OS X 개발자 포럼
  [ FORUM ]   [ WIKI ] 
[ View ]  [ Edit ]  [ Attachments ]  [ History ]    [ Home ]  [ Changes ]  [ Search ]  [ Help ] 
페이지 편집 암호는 osx/cocoa 입니다 

카테고리와 프로토콜

지난 6월 23일 부터 27일까지는 전 세계의 맥 개발자들에게 축제기간이었다. WWDC(World Wide Developers Conference)가 열린것이다.
새로운 IDE와 향상된 컴파일, 디버깅기능, 새로운 버젼의 OS(Panther), 새로운 하드웨어, 새로운 주변기기가 쏟아져 나온 것이었다.
사실 이번 WWDC기간에 세션에 참가해서도 많은걸 배웠지만 몇몇 애플에 근무하는 개발자들과의 만남이 더욱 인상에 남았다.
애플의 소프트웨어 개발자는 200명 정도라고 한다! 정말 놀라지 않을 수 없다.
애플이 쏟아내는 제품들을 보면 과연 200명으로 그걸 다 할 수 있는지 의심이 들지 않을 수 없다. MacOS X, 개발도구, 퀵타임, iApplication들(iPhoto, iChat, iTunes, iDVD...), 키노트, 파이널 컷 시리즈, 웹오브젝트, 애플웍스, 사파리, 각종 서버용 관리툴 등등.
마이크로소프트의 맥비지니스유닛(맥 관련 제품을 개발하는 부서)의 총원이 대략 150명 가량된다. 여기서 만들어내는 제품이 워드, 엑셀, 파워포인트, 앙트라쥬(아웃룩 익스프레스와 같다고 생각하면 된다.), MSN메신저, 미디어 플레이어, 인터넷익스플로러이다.
대충 어림짐작해도 애플직원 1명당 처리하는 일이 거의 마이크로소프트 직원 10명 이상의 일꺼리라고 봐도 될것 같다.
그런데 필자가 애플 주위를 어슬렁 거렸을때 애플직원들이 매우 열심히 일하는것 같아보이지는 않았다(우리 나라의 기준으로) 그렇다고 애플 직원들이 마이크로소프트 직원들보다 더 뛰어나다고 보기도 힘들것 같다. (마이크로소프트는 각 대학에서 뛰어난 인재를 많이 끌어모으기로 유명하다.)
그렇다면 과연 이런 생산성의 차이는 어디서 오는것일까?
뭐 사실 애플개발자들이 혹자가 말하는 애플 광신도(?)이기 때문에 마이크로소프트의 개발자 보다 정신무장이 더 잘 되어있을 수도 있다고 생각할 수도 있겠지만 필자가 듣기로는 애플에서는 애플광신도들을 뽑지는 않는다. 오히려 공정하게 바라보는 시각이 없을 수 있다면서 꺼린다고 한다.
필자는 맥 플랫폼의 선진적인 개발환경과 오픈소스 정책이 생산성에 큰 도움이 되고 있다고 조심스럽게 추측해본다. 그 중심에 코코아가 있는 것이다. 전세계에서 코코아로 가장 많은 프로젝트를 수행하는 애플에서 코코아의 개발 퍼포먼스에 대해서 공식적인 언급은 없었지만 미루어 짐작할 수 있는 부분이다.

지난달에 이어서 이번 달에는 오브젝티브-C의 중요한 두가지 기능인 카테고리와 프로토콜에 대해서 알아볼 것이다.
사실 지난달 연재도 너무 딱딱하게 진행된것 같고 이번달도 무척 딱딱할것 같은 느낌이 벌써 든다. 하지만 이 부분들을 제대로 이해해야지 제대로 코코아의 장점들을 살릴 수 있을것이라고 생각한다.
매우 어렵지는 않은 내용이므로 천천히 읽어보면 이해하기 어렵지 않을것이라 생각하고 또 설령 지금 이해가 안되었다 하더라도 이 기능들을 지금 당장 다 사용하는 것은 아니기 때문에 뒤에 진행되는 연재를 보면서 기억이 안나면 다시 돌아와서 봐도 좋을것이다. 지금 당장은 이해가 잘 안되어도 나중에 예제 코드를 보면서 다시 보면 훨씬 쉽게 와닿을 수 있을것 같기 때문이다.

Categories

카테고리에 대해서 설명을 하자면 가장 간단하게 말해서 한개의 클래스 안에서 여러 메쏘드들을 적당한 기준으로 분류해서 정리해 줄 수 있게 해주는 기능이다. 물론 이것만 있는것은 아니다. 오브젝티브-C의 카테고리를 잘 이용하면 C++같은 데서는 상상할 수도 없는 마술같은 일이 가능해지기도 한다. 예를 들면 클래스를 상속하지 않고 기존 클래스를 확장 할 수 있는 방법을 제공한다. 비록 그 클래스의 소스가 없다고 하더라도 말이다.

카테고리의 사용 목적은 아래와 같다.

- 클래스를 연관된 몇개의 그룹으로 나누어서 관리할 수 있게 해준다. (즉 하나의 클래스를 몇개로 조각내에서 관리할 수 있게 해준다. 구현 파일의 크기가 커지고 메쏘드들이 많아지면 상당히 유용하다. 또한 공동작업을 하게 될때 각각의 개발자들이 자신의 작업 영역을 같은 클래스 내에서도 명확하게 구분 짓게 할 수 있다.)
- 기존의 클래스를 상속 받지 않고 새로운 메쏘드를 추가 할 수 있게 해준다.
- informal protocl을 구현할때 사용된다.


클래스에 카테고리 추가하는 방법


클래스에 카테고리를 추가하는 방법은 간단하다. 인터페이스 파일에 카테고리로 분류해서 메쏘드를 정의한 다음 카테고리 이름과 같은 파일의 구현파일을 작성하면 된다. 카테고리는 새 클래스를 만드는것이 아니고 기존 클래스에 메쏘드가 더 추가되는것을 말한다.
#import "ClassName.h"

@interface ClassName (CategoryName)
method declarations
@end


#import "CategoryName.h"

@implementation ClassName (CatrgoryName)
method definitions
@end

카테고리는 위와 같은 방법으로 사용하면 된다.

예를 들면 애플에서 제공하는 레퍼런스에서 NSString클래스를 볼 수 있는데 그것과 별개로 NSString Additions라고 된 부분도 볼 수 있다. 이것은 NSString은 기본 클래스이고 NSString Additions는 카테고리로 더 추가된 경우를 말한다.
그곳에는 아래와 같은 메쏘드도 들어있다.
- (void) drawAtPoint: (NSPoint )aPoint withAttributes: (NSDictionary *) attributes

이 메쏘드는 이름에서 짐작 가능하듯이 화면에 문자열을 그려주는 역할을 한다.
필자가 가장 재미있게 생각하는 부분으로 코코아 프래임웍은 그려질 객체에 그려주는 메쏘드들이 존재한다. MFC의 CString에는 그런 부분이 존재하지 않는다.
어느것이 더 객체지향적인지에 대한 논의를 하기 전에 이 메쏘드를 소개하는 이유는 이 메쏘드가 카테고리로 구현되었기 때문이다. 즉, NSString에 기본적으로는 드로윙 하는 메쏘드가 존재하지 않지만 카테고리를 이용해서 추가하게 된 것이다.
원한다면 카테고리로 새로운 메쏘드들을 더 추가할 수 있다. 물론 NSString의 소스코드도 필요없다.
또한 카테고리로 추가된 메쏘드들은 일반적인 다른 메쏘드 처럼 상속되기도 한다.(이점은 아주 중요한 문제로 색다른 문제를 야기시키기도 한다.)

카테고리 사용예


자 그럼 실제 카테고리를 어떻게 쓰는지 한번 보자.
K&R의 유명한 The C Programming Language란 책엔 섭씨, 화씨 온도를 변환하는 예제가 있다. 이것에서 영감을 받은(?) 예제이다.(예제가 썰렁하다고 필자를 욕해도 어쩔 수 없다. :( 절대로 이런데 카테고리를 남용하지 말고 또 코드가 전혀 객체지향적이지 않다거나 consistency가 없다고 비판하지 말기바란다. 짧은 예제 만드느라 더 힘들었다.)
먼저 NSExample이라는 클래스를 만들어서 이 클래스가 계산을 하게 해보자.
먼저 프로젝트 빌더 또는 Xcode에서 새 프로젝트를 선택한다. 그 다음 아래쪽에 있는 파운데이션 툴을 선택해서 프로젝트를 생성시킨다. 일반적으로 코코아 애플리케이션 같은걸 사용하겠지만 현재는 간단한 예제를 만들것이기 때문에 UI를 사용하지 않는 파운데이션 툴을 선택한 것이다.

#import <Foundation/Foundation.h>
#import "NSExample.h"

int main (int argc, const char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    // insert code here...
    int ret;
    NSExample *example = [[NSExample alloc] init];
    
    [example setFahr:200];
    [example calc];
    ret = [example celsius];
    NSLog(@"%d\n", ret);
    
    [example release];

    [pool release];
    return 0;
}
<main.m>

메인 프로그램은 위와 같다. 단순히 화씨 온도를 입력한 후에 계산하라는 메시지를 날리고 섭씨 온도를 받아오는게 전부이다. NSLog는 printf와 비슷한데 NSString값을 로그창으로 출력해주는 역할을 한다. 전에도 설명했듯이 @을 붙인 문자열은 NSString을 말한다.
NSAutoreleasePool과 객체의 생성과 소멸에 대해서는 뒤에 설명이 있으니 일단 넘어가도록 하자.
#import <Foundation/Foundation.h>


@interface NSExample : NSObject {
@private
    int fahr, celsius;
}

- (int)fahr;
- (void)setFahr:(int) aFahr;
- (int)celsius;
- (void)setCelsius:(int) aCelsius;
- (void)calc;

@end
<NSExample.h>

지난달에 설명한 방법대로 일반적인 클래스를 선언했다.
#import "NSExample.h"


@implementation NSExample

- (int)fahr
{
    return fahr;
}

- (void)setFahr:(int)aFahr
{
    fahr = aFahr;
}

- (int)celsius
{
    return celsius;
}

- (void)setCelsius:(int)aCelsius
{
    celsius = aCelsius;
}

- (void)calc
{
    celsius = 5 * (fahr - 32) / 9;
}

@end
<NSExample.m>

구현 역시 단순하다. 자 여기까지는 복습이라고 생각하고 다음 단계로 넘어가보자.
여기서 calc를 제외한 다른 메쏘드들은 accessor라고 이야기했었다. 지금은 소스코드가 짧아서 그렇지만 만일 소스코드가 무진장 길어졌다고 상상하고 결국 이 부분을 따로 관리하고 싶다는 생각을 하게 되었다고 하자.
이제부터 accessor메쏘드를 따로 카테고리로 분리시키겠다. 헤더파일을 아래와 같이 수정했다.
#import <Foundation/Foundation.h>

@interface NSExample : NSObject {
@private
    int fahr, celsius;
}

- (void)calc;

@end


@interface NSExample (Accessors)

- (int)fahr;
- (void)setFahr:(int) aFahr;
- (int)celsius;
- (void)setCelsius:(int) aCelsius;

@end
< NSExample.h>

구현파일은 아래와 같이 수정했다.
#import "NSExample.h"


@implementation NSExample

- (void)calc
{
    celsius = 5 * (fahr - 32) / 9;
}

@end


@implementation NSExample (Accessors)

- (int)fahr
{
    return fahr;
}

- (void)setFahr:(int)aFahr
{
    fahr = aFahr;
}

- (int)celsius
{
    return celsius;
}

- (void)setCelsius:(int)aCelsius
{
    celsius = aCelsius;
}

@end
<NSExample.m>

이 간단한 예제에서 카테고리 사용법은 다 끝난거나 마찬가지다. 실제로 기본 사용법은 아래와 같다. 만일 필요하다면 카테고리 이름으로 새로 파일을 만들어서 구현 할 수도 있다.

자 그럼 기존 클래스에 새로운 기능을 추가해보도록 하자. 현재 NSExample클래스는 단순하며 실제로 K&R 책의 예제와 같지도 않다. K&R책의 예제에서는 루프를 돌리면서 온도를 쭉 출력하는 기능이 있다. 이 기능을 추가하도록 해보자. 단, 기존의 NSExample클래스는 손대지 않고 말이다.
즉, NSExample클래스를 벤더에서 제공한 클래스라고 생각하고 이제 개발자가 기존에 제공된 클래스를 상속 받지 않고 기능을 추가하는 작업을 한다고 생각하자.
일단 NSExample은 단 한줄도 안건드린다고 약속했으니 새로 파일을 만들자. NSExampleAdditions.h와 NSExampleAdditions.m을 만들었다.
#import <Foundation/Foundation.h>
#import "NSExample.h"

@interface NSExample (NSExampleAdditions)

- (void)loop;

@end
<NSExampleAdditions.h>

#import "NSExampleAdditions.h"


@implementation NSExample (NSExampleAdditions)

- (void)loop
{
    int lower, upper, step;
    
    lower = 0;
    upper = 300;
    step = 20;
    
    fahr = lower;
    while ( fahr <= upper ) {
        celsius = 5 * (fahr - 32) / 9;
        NSLog(@"%d\t%d\n", fahr, celsius);
        fahr = fahr + step;
    }
}

@end
<NSExampleAdditions.m>

그리고 loop라는 메쏘드를 만들어서 구현했다. 보면 알겠지만 fahr와 celsius변수는 NSExample의 것을 그대로 이용했다. 
#import <Foundation/Foundation.h>
#import "NSExample.h"
#import "NSExampleAdditions.h"

int main (int argc, const char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    // insert code here...
    NSExample *example = [[NSExample alloc] init];
    
    [example loop];
    
    [example release];

    [pool release];
    return 0;
}
<main.m>

main.m은 위와 같이 바꾸었다.
자, 이제 카테고리의 가장 중요한 기능인 파티션 해주는 기능과 새로운 메쏘드를 추가해주는 기능을 확인해보았다.
여기서 예제를 만들지는 않았지만 만일 기존의 메쏘드와 같은 메쏘드를 카테고리로 추가하게 되면 기존의 메쏘드를 가려버리게 된다. 즉, 상속을 해도 기존의 메쏘드를 사용할 방법이 없다는것이다. 만일 상속을 받았다면 super를 이용해서 기존의 메쏘드에 접근 할 방법은 있지만 카테고리는 그렇지 못하다. 이것은 잘 생각해보면 큰 문제일 수도 있다.
주의를 주자면 카테고리는 어떻게 사용하냐에 따라서 매우 위험할 수도 있다. 자칫 잘못하면 전혀 엉뚱한 결과를 낳을수도 있다는 것이다. 만일 공용으로 사용하는 특정 클래스의 메쏘드를 카테고리로 바꿔버리면 다른 작업자들이나 소스의 다른 부분에서 문제를 일으킬 수 있다.
즉, 메쏘드를 덮어버리는 카테고리의 남발은 상당히 위험하며 신중해야한다. 하지만 카테고리의 가장 멋진 부분은 예를 들면 NSString에서 특정 인코딩을 지원해야하는데 NSString에서는 그 인코딩을 지원하지 않는다고 가정하자. 카테고리가 없으면 NSString을 상속받아서 기능을 추가하고 그 클래스를 이용해야 할 것이다. 이것은 의외로 상당히 번거로운 문제를 야기할 수있다. 만일 이미 완성된 수만라인의 코드에서 NSString을 모두 교체하고 확인할려면 상당한 부담이 될것이다. 하지만 이런 경우 카테고리는 아주 단순하고 명확한 방법을 제시해줄 수 있다.

카테고리의 또 다른 기능은 informal protocol은 카테고리와 프로토콜 양쪽에 걸쳐있는 부분이라서 이것에 대해서는 뒤에 프로토콜을 설명할때 같이 설명하도록 하겠다.


루트 클래스의 카테고리


카테고리는 어떤 클래스에도 메쏘드를 추가할 수 있는데 만일 루트 클래스라면 좀 특별해진다. 지난달에 설명했듯이 코코아의 모든 클래스의 루트 클래스는 NSObject이므로 NSObject에 카테고리로 추가된 메쏘드는 모든 오브젝트에 공통으로 사용되게 된다. 즉, 자칫 매우 위험한 코드가 될 수 있다. 상속된 모든 클래스에서 예상치 못한 동작을 야기할수도 있다. 그래도 만일 꼭 해야하는 경우엔 루트 클래스의 super는 없으므로 super로 메시지를 보내지 못하며(컴파일러가 에러를 낸다) 클래스 오브젝트가 루트 클래스의 인스턴스 메쏘드를 실행 할 수 있다는데 주의 해야 한다.(일반적으로 인스턴스화 되지 않은 클래스 오브젝트에서 바로 인스턴스 메쏘드를 호출할 수 없다. 하지만 특별히 루트 클래스의 인스턴스 메쏘드는 상속받은 다른 클래스 오브젝트에서도 사용 할 수 있다. 만일 NSObject의 인스턴스 메쏘드를 밑에서 오버라이딩 해버리면 이러한 특징은 사라진다.)


Protocols

프로토콜은 클래스 상속에서 떨어져 있는 메쏘드 정의 리스트라고 말할 수 있다. 즉 클래스 상속의 관계와 무관하게 또, 특정 클래스 정의와 무관하게 클래스들 간의 공통적인 메쏘드를 정리할 수 있는 메쏘드 리스트 인것이다.(자바의 인터페이스와 유사하다)

프로토콜의 주용도


크게 두가지 목적에서 프로토콜을 주로 사용하는데,
하나는 클래스를 알 수 없는 어떤 객체를 받아서 그 객체의 사용여부를 판단할 때이다.
예를 들어 분산 객체 환경과 같은 경우, 다른 호스트에서 선언되고 생성된 어떤 객체를 네트웍을 통해 전달받아 이 객체를 사용할 때 필요한 프로토콜을 만족하는지 conformsToProtocol:메쏘드를 이용해 확인한 후 사용하게 된다.
또 다른 주요한 용도로 어떤 목적을 위해 반드시 구현해야하는 메쏘드 집합을 선언할 때이다.
예를 들어 코코아의 NSCoding프로토콜은 코코아 객체의 archiving mechanism으로 이 프로토콜의 메쏘드를 모두 구현해야 비로소 archive가능한 객체가 된다.

프로토콜의 사용

프로토콜의 정의는 다음과 같이 할 수 있다.
@protocol ProtocolName
method declarations
@end

만일 어떤 클래스를 선언할때 프로토콜을 추가할려면 아래와 같이 한다.
@interface ClassName : ItsSuperclass <protocol list>

또한 카테고리에 프로토콜을 추가할 수 있는데 아래와 같이 하면 된다.
@interface ClassName (CatergoryName) <protocol list>

만일 동시에 여러개의 프로토콜을 지원하게 할려면 콤마(,)를 넣어서 추가할 수 있다.
@interface Formatter : NSObject < Formatting, Prettifying >


Protocol을 따르는지 확인


소스코드에서 @protocol() directive를 이용하므로써 프로토콜 오브젝트를 사용할 수 있다.
Protocol *myProtocol = @protocol(MyProtocol);

만일 어떤 오브젝트가 주어지면 conformsToProtocol: 메시지를 오브젝트에 보내서 프로토콜을 따르는지 확인할 수 있다. 결국 conformsToProtocol: 메시지를 이용해서 그 오브젝트가 특정 프로토콜을 따르는지 확인한 후에 사용 할 수 있다.
if ( [receiver conformsToProtocol:@protocol(MyProtocol)] ) {
	[receiver myMethod];
}

프로토콜의 특징

프로토콜은 상속이나 중첩 선언되지 못하며 선언된 모든 메쏘드는 구현되어야 한다. 만일 메쏘드들을 부분적으로 사용해야 할 때에는 뒤에 나오는 인포멀 프로토콜을 이용해야 한다.

프로토콜 사용예

카테고리때와 마찬가지로 파운데이션 툴로 간단히 프로토콜의 작동을 보이는 예제를 만들어 보자.
먼저 MyProtocol.h를 다음과 같이 만든다.
@protocol MyProtocol

- (void)myMethod;

@end
<MyProtocol.h>

이 MyProtocol을 준수하는 모든 오브젝트는 myMethod를 구현해야한다.

NSObject를 상속받은 MyObject를 만들 차례이다.
#import <Foundation/Foundation.h>
#import "MyProtocol.h"

@interface MyObject : NSObject <MyProtocol>
{

}

@end
<MyObject.h>

NSObject를 상혹 받은 후 아무 내용을 추가하지 않았다. (실제로는 이렇게 하지는 않을것이다.) 단지 차이가 있다면 MyProtocol을 준수할것이라고 선언한것 뿐이다.
#import "MyObject.h"


@implementation MyObject

- (void)myMethod
{
    NSLog(@"My Method");
}

@end
<MyObject.m>

구현에서도 역시 MyProtocol에 정의된 myMethod만을 구현했다.
여기서 주의 할점은 프로토콜에 정의된 모든 메쏘드를 구현하지 않으면 실행시간에 없는 메쏘드를 찾다가 익셉션을 발생시키는데 이 경우 메쏘드 내의 남은 부분을 처리하지 않고 빠져나와서 버그를 발생시킬 수 있으나 -conformsToProtocol:메시지에 의해 프로토콜 검사를 할때 실패하기 때문에 꼭 확인을 해주고 사용하는게 좋다.
이 경우 컴파일 타임에서는 워닝을 내므로 꼼꼼하게 살펴봐야 할 것이다.
#import <Foundation/Foundation.h>
#import "MyObject.h"

int main (int argc, const char * argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    id myObject = [[MyObject alloc] init];
    id nsObject = [[NSObject alloc] init];
    
    if ( [myObject conformsToProtocol:@protocol(MyProtocol)] ) {
        [myObject myMethod];
    }
    if ( [nsObject conformsToProtocol:@protocol(MyProtocol)] ) {
        [nsObject myMethod];
    }
    
    
    [myObject release];
    [nsObject release];
    [pool release];
    return 0;
}
<main.m>

마지막으로 main.m의 구현이다. 비교예를 들기 위해서 MyObject(MyProtocol 프로토콜 준수)와 NSObject(MyProtocol을 준수하지 않음)를 같이 생성한 다음 -conformsToProtocol: 메시지를 이용해서 myMethod를 불러주게 했다.
생성된 객체가 정확히 뭔지 모른다는것을 보이기 위해서 id타입으로 캐스팅 했다. 실행결과를 보면 myObject의 myMethod는 불리지만 nsObject에서는 myMethod를 부르지 않는다.
만일 MyObject 이외의 또 다른 MyProtocol을 준수하는 객체에 대해서는 메소드를 호출 할 것이다.


Informal Protocols

프로토콜을 이용하지 않고 카테고리를 선언하고 구현하지 않는 방법으로 프로토콜과 비슷한 기능을 구현 할 수도 있다. 이것을 인포멀 프로토콜이라고 하는데 모든 서브클래싱 된 클래스들에서 구현해도 되고 하지 않아도 될 메쏘드 그룹을 정의 하는데 이용한다.
인포멀 프로토콜은 흔히 NSObject의 카테고리로 선언되는데 NSObject에서 상속된 모든 클래스에 광범위하게 영향을 미치게 된다. 그래서 일반적인 프로토콜을 사용하는데에 사용하는것은 피하는것이 좋고, 모든 메쏘드의 구현을 선택적으로 할 수 있기 때문에 딜리게이트 처리 같은 부분에서 사용된다.

예들 들면, 코코아의 NSTableDataSource프로토콜은 informal protocol이다. 이는 다음과 같이 선언되어있다.
@interface NSObject(NSTableDataSource)
- (int)numberOfRowsInTableView:(NSTableView *)tableView;
- (id)tableView:(NSTableView *)tableView 
   objectValueForTableColumn:(NSTableColumn *)tableColumn row:(int)row;
// optional
- (void)tableView:(NSTableView *)tableView setObjectValue:(id)object 
   forTableColumn:(NSTableColumn *)tableColumn row:(int)row;

// optional - drag and drop support
- (BOOL)tableView:(NSTableView *)tv writeRows:(NSArray*)rows 
   toPasteboard:(NSPasteboard*)pboard;
    // This method is called after it has been determined that a drag should begin, 
    // but before the drag has been started.  To refuse the drag, return NO.  
    // To start a drag, return YES and place the drag data onto the pasteboard 
    // (data, owner, etc...).  
    // The drag image and other drag related information will be set up and 
    // provided by the table view once this call returns with YES.  
    // The rows array is the list of row numbers that will be participating in the drag.

- (NSDragOperation)tableView:(NSTableView*)tv 
   validateDrop:(id <NSDraggingInfo>)info proposedRow:(int)row
   proposedDropOperation:(NSTableViewDropOperation)op;
    // This method is used by NSTableView to determine a valid drop target.  
    // Based on the mouse position, the table view will suggest a proposed drop location. 
    // This method must return a value that indicates which dragging operation 
    // the data source will perform.  
    // The data source may "re-target" a drop if desired by calling 
    // setDropRow:dropOperation: and returning something other than
    // NSDragOperationNone.  One may choose to re-target for various reasons 
    // (eg. for better visual feedback when inserting into a sorted position).

- (BOOL)tableView:(NSTableView)tv acceptDrop:(id <NSDraggingInfo>)info 
   row:(int)row dropOperation:(NSTableViewDropOperation)op;
    // This method is called when the mouse is released over an outline view that 
    // previously decided to allow a drop via the validateDrop method.  The data source 
    // should incorporate the data from the dragging pasteboard at this time.

@end

informal protocol이 루트클래스인 NSObject클래스에 카테고리로 붙여놓은 이유는 어떤 클래스에서도 이 카테고리의 메쏘드를 구현할 수 있도록 하기 위해서이다. 만약 MyDataSource라는 클래스가 이 프로토콜을 사용하고 싶으면 그냥 MyDataSource클래스에 위에서 선언된 메쏘드들을 구현해주기만 하면 된다.
이 NSTableDataSource informal protocol의 경우는 선언된 메쏘드들중 처음의 두 메쏘드는 반드시 구현해야하지만 나머지 메쏘드들을 필요에 따라 구현해 주면 된다. 즉, 세번째 메쏘드는 테이블 데이터 갱신이 필요할 경우에만 구현하면 되고, 나머지 세 메쏘드들은 드래그앤드롭의 지원여부에 따라 구현해주면 된다.

Link to this Page

  • Objective-C last edited on 9 May 2006 at 1:40 pm by 210.217.95.227

Since 2001, OSXDEV.ORG