lonelycat's cellar

KT 폰스토어에서 아이폰 예약을 했다...
근데 선택사항 중에 3g로 기변 / 보상기변이 전혀 이해가 안되서
갖고 있는 폰이 3g라서 3g로 기변을 선택했더니만
잘못 선택했다고 신청서가 자동폐기 되었다네?
그건 좋다 이거야, 미리 확인 안한 내 잘못도 있으니까.

근데 신청서는 어디서 수정하냔 말이지...
사이트를 아무리 뒤져도 알 수가 없네.
설마 주문 취소하고 다시 신청하라고? 장난하나?
서비스 프로세스는 누가 만들었는지 참 한심하다...
뭐 이거까지도 넘어가 준다 이거야.

근데 왜 콜센터는 전화를 안받지?
아침 9시에 전화해서 대기시간 30초였는데 안받더라는 얘기도 있데?
그리고 QA게시판에 왜 아이폰 관련 질문엔 답을 안다는데?
이건 일부러 대응을 안한다는 얘기잖아?

KT, 니들 그렇게 서비스해서 업계 1위 하겠냐?
SKT가 잘하는 건 별로 없지만 그래도 고객 충성도는 계속 유지하고 있는 편인데
KT 니들은 아이폰이라는 좋은 찬스를 가지고도 살리지를 못하네.

아무튼 니들은 1위하긴 글러먹은 기업이야...

Protocol의 종류 : Formal Protocol

- formal protocol은 다음과 같이 @protocol이라는 directive를 이용해서 선언한다.

@protocol ReferenceCounting
- (int)refCount;
- incrementCount;
- decrementCount;
@end

- protocol 이름은 global하게 access할 수가 없다. protocol은 클래스랑 연관을 시켜서 써주는 것이지 단독적으로 쓰는것이 아니기 때문이다. 즉 어떤 protocol을 쓰려면 class가 그 프로토콜을 “준수”해야 하는 것이다. 즉 그 프로토콜을 adopt 혹은 채용해야 한다.

@interface ClassName : ItsSuperclass < protocol list >
@interface ClassName ( CategoryName ) < protocol list > // 카테고리가 protocol을 받으려면
@interface ClassName ( CategoryName ) < protocol_1, protocol_2 >

- 단 protocol을 받아들일 클래스나 카테고리 파일에서는, 반드시 그 프로토콜이 선언된 헤더파일을 import해야만 한다. 그리고 그렇게 받아들여진 프로토콜안에 정의된 method들은 클래스나 카테고리 인터페이스의 다른 부분에서 또 선언되면 안된다.
  -> 당연한 듯..

- 물론 프로토콜 method외엔 아무 method도 가지지 않는 클래스도 있을 수 있다.

@interface Formatter : NSObject < Formatting, Prettifying >
@end

- 한 클래스나 카테고리가 일단 어떤 프로토콜을 준수하겠다고 한다면,그 클래스나 카테고리는 준수하고자 하는 프로토콜에 선언된 모든 method를 다 구현해야 한다. 그렇지 않으면 컴파일러가 경고를 하게 된다.

- formal protocol은 선언시에 @protocol이란 특별한 directive를 써 놓았을 뿐, 그 구현은 역시 informal protocol과 마찬가지로 class내에서 한다.
Category는 어떤가? 그 선언과 구현이 별도로 되어 있다. 즉 클래스에 종속되어 있지 않다.
그렇다면 Category와 Protocol의 궁극적인 차이는 무엇일까?
Objective-C의 장점이 알지 못하는 객체에다가 메시지를 보내고, 그 헤더파일이 없는 클래스를 상속이 아닌 수평적인 수준에서 새 함수를 더 넣을 수 있다는 것이다. Category는 이미 있는 클래스를 수평적으로 확장을 할 때, 유용하다. 단 그때, 그 클래스의 소스코드가 없을 수 있다. 그러므로 별도의 장소에서 다음과 같이 한다.

@implementation ClassName ( CategoryName )
method definitions
@end

하지만 protocol인 경우엔 저 “ClassName” class 자체에서 하게 된다. 즉 protocol인 경우엔, 내가 지금 만드는 클래스가 어떤 것을 다 가져야 할지 이미 알고 있는 경우란 소리다.
Category와 Protocol 개념은 클래스들을 그 행위로서 구분지어줄 수 있는 것들이지만, 이렇듯 미리 무엇을 할지 알고 있느냐 없느냐에 따라 용례가 갈린다고 볼 수 있다. 또한 Category의 경우에는 뭔가 해당 클래스의 versioning이라는 점이다. 결국 보면 protocol과 비슷해질 수는 있겠지만, 개념적으론 좀 차이가 있다.
 -> Category는 (소스코드가 없는) 클래스를 수평적으로 확장(Versioning 개념).
     Protocol은 소스를 알고 있는 여러 클래스들에게 동일한 처리 규약(처리내용은 다르겠지만 인터페이스는 같다)을 주는 것. 정도 일려나?
     사용례를 봐야 좀 확실하게 개념이 잡힐 듯. Category는 그렇다처도 Protocol은 애매하다...

출처: Objective‐C Language Reference 박종암 jongampark@gmail.com
protocol의 이용부분부터는 박종암님의 pdf를 보고 썼음.. 문제있으면 알려주세요~

Protocol의 종류 : Informal Protocol

Category 선언내에 method를 선언하면 그게 바로 informal protocol이 된다.

@interface NSObject ( RefCounting )
- (int)refCount;
- incrementCount;
- decrementCount;
@end

위의 예에서 볼 수 있듯이, informal protocol은 대개 NSObject 클래스에 대한 카테고리로써 선언한다. 그렇게 하면, NSObject에서 나온 새끼 클래스들이 모두 다 사용할 수 있기 때문이다. 물론 다른 클래스에 대한 category로써도 정의할 수 있다. 그럼 그 클래스에서 나온 클래스들만 사용할 수 있다.
여기서 주의할 점은, 카테고리 interface를, protocol을 선언하기 위해서 쓸때는, 거기에 상응하는 implementation을 가지지 않는다는 점이다. 대신에 그 method들을 가지는 protocol을 구현하는 클래스들이 그 자체의 interface 파일에서 다른 method들과 마찬가지로 구현하게 된다.
다시 말해보자. 생긴 걸로 봤을때, informal protocol은 Category와 완전히 같다. 단지 차이점은 Category는 구현에 대한 부분도 역시 카테고리로 만들어서 넣어주나, informal protocol일 경우엔 그 구현을 해당 클래스에서 method로 직접 해 준다는 것이다.
또한 informal protocol은 category를 선언하는 방식을 좀 바꿔서 method들의 리스트를 써 놓기는 하지만 어떤 특정 클래스나 구현에 고정시켜 놓지는 않는다.
informal protocol은 구현하기가 이렇게 편하다. 하지만 단점이 있게 마련이다. 편한거치고 단점없는게 어디 있겠는가? 즉 language로부터 그다지 많은 지원을 받지 못한다. 표로 정리해 보자.

compile time시  :  type checking을 하지 않는다
run time시   :   한 객체가 그 protocol을 conform(준수)하는지 알수 없다.

이런 단점이 싫다면 그때는 다음에서 알아볼 formal protocol을 사용하면 된다. 그럼 이런 informal protocol은 언제 쓰면 좋을까? 그건, protocol에 정의된 method들을 구현하는게 굳이 필요하지 않을때이다. 즉 delegate같은 것을 구현할 때 쓰면 편하다. 즉 다른 객체 대신에 일을 수행하는 객체를 만들때 좋다.

NOTE : 엄밀하게 보면 informal protocol은 없는 것으로 보인다. 이것은 Category의 다른 이용일 뿐이다. Category와의 차이점은 앞에서도 나와 있지만, 그 구현을 클래스내에 하느냐 아니면 따로 준비된 곳에 하느냐의 차이이다. 필자가 Objective-C를 처음 접하면서, 처음엔 참 쉽게 잘 만들어졌다고 생각하면서도 한동안 보지 않다가 다시 보면 헷갈리고, 복잡하다고 여긴 부분이 바로 이 부분때문이다. syntax로 category와 informal protocol이 명확하게 구별이 안된다.
또한 그 사용 목적도 그렇다. Category의 원목적이 이미 있는 클래스에 뭔가를 더 추가해 넣을때, 그리고 attribute/property가 아닌 behaviour로 클래스들을 구분할 때 쓰기 위함인데, 결국 protocol과 비슷하지 않은가? protocol도 그 protocol을 conform하는 것끼리의 구별하는 목적이 있다. Objective-C는 NeXT의 몰락과 함께 사실 그 명맥이 다했으며 C++처럼 활발한 개발과 확장, 혹은 정제가 이루어지지 않았다. 언어의 간결함에 대해선 C++보단 더 좋으나, 뭔가 아직 미완성인 듯한 느낌이 나는 부분이 바로 이 부분이다. 앞으로 Apple이 다시 이 Objective-C를 발전시켜 나가면 좋겠다.

--> 안 쓰는게 좋을 듯 함... category와 protocol의 명확한 사용을 위해서...

Protocol 이용 : 비계층적 유사성(Non-Hierarchical Similarities)

- 여러 클래스가 같은 method를 구현하게 된다면, 그런 클래스들은 한 abstract class 밑으로 들어갈 수 있으며, 그 abstract class에서 공통된 method들을 선언해 놓게 된다. 각각의 sub class에선 그런 method들을 각각의 용도에 맞게 구현하면 된다. 이렇게 함으로써 그런 클래스들은 상속에 의한 계층적 구조에서, 그리고 같은 abstract class를 그 조상으로 한다는 점에서 유사성을 가지게 된다.
- 하지만 때때로 abstract class에 공통적인 method를 다 잡아 넣을 수 없는 경우도 있다. 이를테면, 전혀 관련이 없는 클래스들이지만 유사한 method를 가지고 있을 수도 있는 것이다. 이럴 경우에 상속관계로 묶어 놓기엔 좀 곤란할 수 있을 것이다. 예를 들어, 완전히 다른 클래스들에 reference counting을 위해서 어떤 method를 구현해 넣는다던가 하는 것이 그런 예겠다.

Protocol 이용 : 익명의 객체를 위한 Interface를 선언하기

Protocol 이용 : 익명의 객체를 위한 Interface를 선언하기
  -> 뭔 소린가 했는데, 익명의 객체-클래스-를 만들 때 반드시 구현해야할 메소드를 선언 가능하다는 얘기인 듯.
자바의 interface로 보면 될 듯.

- 라이브러리나 framework 제작자는 클래스 이름이나 인터페이스 파일로는 알 수 없는 객체를 만들수 있다. 그런 이름이나 클래스 인터페이스가 없다면, 그런 것을 가져다 사용하는 사람들 입장에선 도무지 그런 클래스의 instance를 만들래야 만들수가 없겠다. 아니면 원제작자는 이미 만들어 놓은 instance를 제공해 주어야만 한다. 보통의 경우, 다른 클래스에 정의된 method는 사용할 수 있는 객체를 리턴해주게 끔 만든다.
   id formatter = [receiver formattingService];
이 예에 있는 객체, 즉 반환된 객체는 그 class identity가 없다. 아니면 적어도 그 원 제작자가 바깥에 공개하기를 꺼리는 것일 거다. 이런 객체를 쓰게 하려면, 적어도 몇몇개의 메시지에는 반응을 하도록 만들어야 한다. 그러므로 이런 것은 protocol로써 정의된 method들과 연결시켜 놓을 수 있다.
 -> id 타입으로 반환된, 공개하길 꺼리는 object를 protocol로 정의된 method와 연관시켜 놔서, 그 object를 사용할 수 있게 해야한다는 말인 듯.

- 각 프로그램들은 각자의 구조와, 클래스, 그리고 동작하는 논리가 있지만, 다른 프로그램이 어떻게 움직일지 여러분이 꼭 알아야 하는 것은 아니다. 그 프로그램의 바깥에 있는 사람 입장에선, 어떤 메시지를 보낼 수 있고, 어디다 보내야 할지를 알면 그만이다. 이것은 결국protocol과 receiver이 무엇이냐를 알기만하면 된다는 것이다.
다른 곳에서 오는 메시지를 받아 처리할 객체를 공개하는 프로그램은, 반드시 그 메시지에 반응할 method또한 공개해야 한다. 메시지를 보내는 측에선 해당 객체의 클래스가 뭐냐에 대해선 알 필요가 없고, 그 클래스를 내부적으로 이용할 필요도 없다. 단지 필요한 것은 protocol뿐이다.
  -> 맞는 말인데 protocol과의 관련성은 잘 모르겠다...ㅠ.ㅠ

Protocol

- 클래스랑 관련 없는, method 선언의 모음
- protocol로 선언된 method를 써야 할 필요가 있다면, 그 클래스는 해당 protocol을 쓰겠다고 하고(adopt), 그 method를 자체 내에서 구현하면 된다.
- 보통 protocol은 관련있는 메소드들 끼리 모아 놓게 된다. 그러므로 어떤 클래스가 그 protocol을 사용하겠다고 하면, 그 클래스는 그 "통신 규약"을 이해하는 클래스가 된다.
  -> protocol에 정의된 메소드들이 통신 규약이 되고, 그 protocol을 사용하는 클래스는 반드시 정의된 메소드들을 구현해야 되므로 통신 규약을 이해하는 클래스가 된다.

- dynamic language의 입장에서 볼때, class를 inheritance와 category에 의거한 "어디에서 상속을 받았나"로 클래스들을 구분해 놓는 것 뿐만 아니라, protocol로 인해서 어떤 클래스들이 서로 비슷한 행동을 하나라는 동적인 구분까지 가능하게 해 준다.
- 아예 클래스의 종류가 다른 것까지도 서로 protocol을 지키면 해당 메시지를 처리하는 것도 가능.

- 언제 protocol을 사용하게 되는지 정리해 보자.
  > 다른 프로그래머들이 구현하게 될 메소드의 선언 (Apple 문서에서 따온 말). 하지만 이 말보다는 "다른 프로그래머들에게 구현하라고 유도해야 할 메소드들의 선언"이라고 하는 편이 더 맞겠다.
  > 오브젝트의 클래스 자체는 숨기면서 그에 대한 인터페이스를 만들어야 할 때.
  > 계층적으로는 전혀 상관 없는 클래스들이지만 뭔가 상호연관성을 가지게 해야 할 필요가 있을때.

- 어떤 한 객체 A 가 있는데, 그것이 helpout이라는 메시지를 다른 객체 B에 보내서 어떤 일을 수행해 달라고 요청한다고 하자. 이때 현재 코딩하고 있는 객체 A에 다음과 같은 함수를 이용해서 객체 B를 기록해 놓을 수 있겠다.

- setAssistant:anObject {     assistant = anObject; }

그리고 이 객체에 메시지를 보낼때는, 그 메시지를 처리하는 측에선 자신이 그 메시지를 처리할 수 있는지를 검사하는 루틴을 넣어야겠다.

- (BOOL)doWork {     ...     // helpOut이라는 메시지에 해당 객체, 즉 assistant가 가르키고 있는 객체가 반응을 하는지를 알 수 있다.     if ( [assistant respondsTo:@selector(helpOut:)] )     {         [assistant helpOut:self];         return YES;     }     return NO; }

  -> 객체B, 즉 assistant가 protocol을 따르도록 하라는 건지? 이 예제만으로는 protocol과는 관련이 없는데?
  > Apple의 문서에서는 protocol을, 정의되어 있지 않은 객체에 메시지를 전달하고자 할 때 쓸 수 있다라고 되어 있다. 즉 아직 만들지 않은, 혹은 다른 사람이 작업하고 있어서, 그 클래스의 구조를 정확하게 모를때, 그 클래스에 어떤 메시지를 전달하는 여러분의 루틴을 만들 수 있다는 말이다. Objective-C는 이렇듯 대상에 대한 정보가 없어도 되는 메커니즘을 가지고 있다.
  -> 이거에 대한 예제라면 OK. 객체B, 즉 assistant의 구조를 몰라도 메시지-helpOut-에 반응하는지를 동적으로 체크해서 전달 가능.

Root Class

- Root 클래스라 함은 상속 관계에서 가장 부모 node의 클래스
- super로 메시지를 보낼 수 없다.
  -> 당연...
- class object는 root class에 정의된 instance method를 억세스할 수 있다.
(보통은 class 오브젝트는 instance method를 실행할 수 없지만 root class의 경우엔 예외이다. )