한국   대만   중국   일본 
오브젝티브-C - 위키百科, 우리 모두의 百科事典 本文으로 移動

오브젝티브-C

위키百科, 우리 모두의 百科事典.
( Objective-C 에서 넘어옴)

오브젝티브-C
Objective-C
패러다임 反映兄 , 클래스 基盤 프로그래밍 , 客體 志向 프로그래밍
設計者 톰 러브 , 브래드 콕스
開發者 애플
發表日 1984年 (40年 前) ( 1984 )
最近 버전 2.0 [1]
파일 擴張字 .h, .m, .mm, .C
웹사이트 developer .apple .com /library /archive /documentation /Cocoa /Conceptual /ProgrammingWithObjectiveC /Introduction /Introduction .html
主要 具現體
클랭 , GCC
影響을 받은 言語
C , 스몰토크
影響을 준 言語
그루비 , 자바 , Nu , 오브젝티브-J , , 스위프트

오브젝티브-C ( 英語 : Objective-C )는 C 프로그래밍 言語 스몰토크 스타일의 메시지 構文을 追加한 客體 志向 言語이다. 現在, 이 言語는 애플 매킨토시 運營 體制 OS X 아이폰 運營 體制 iOS 에서 使用되고 있다. 오브젝티브-C는 애플의 코코아 를 使用하기 위한 基本 言語이며, 元來는 넥스트 의 NeXTSTEP 運營 體制 에서 週 言語였다. 一般的인(generic) 오브젝티브-C는 앞에서 言及한 라이브러리를 使用하지 않는다.

歷史 [ 編輯 ]

1980年代 初, 소프트웨어 工學의 一般的 慣行은 構造的 프로그래밍 의 慣習을 따르는 것이었다. 이 프로그래밍 技法은 프로그램을 잘개 쪼개어 作業하기 쉽도록 만드는 것을 돕기 위한 技法이었다. 하지만 풀어야 할 問題 規模가 커짐에 따라 構造的 프로그래밍 技法의 有用性은 減少하였는데, 더 많은 프로시저가 作成되어야 하다 보니 再使用性이 떨어지고 프로그램 制御 흐름도 複雜해지기 때문이었다.

많은 사람들은 客體 志向 프로그래밍 技法이 이 問題에 對한 解答이 될 수 있지 않을까 하고 생각하였다. 事實, 스몰토크 라는 프로그래밍 言語는 이미 이러한 工學 이슈들을 涉獵하고 있었다. 世上에서 가장 複雜한 시스템들 中 몇몇이 스몰토크 環境에서 作成되었다. 하지만 이 言語에도 한 가지 問題는 있었으니 假想 머신 을 使用하는 點이었다. 스몰토크 의 假想 머신은 이미지(image)라고 불리는 客體 메모리를 두고 여기에 모든 開發 道具들을 貯藏해두었다. 그러다보니 메모리 要求量이 그 當時로는 非合理的일 程度로 늘어났고, 느리게 動作할 수 밖에 없었다. 이는 部分的으로는 假想머신(VM)이나 컨테이너(container) 槪念을 쓸만하게 支援하는 하드웨어가 없었기 때문이기도 했다.

오브젝티브-C는 스텝스톤(Stepstone)이라는 會社에서 일하고 있던 브래드 콕스 (Brad Cox)와 톰 러브(Tom Love)라는 두 硏究員이 만들었다. 亦是 1980年代 初의 일이다. 이 두 사람은 1981年 ITT의 프로그래밍 技術 센터(Programming Technology Center)에서 일하던 時節 스몰토크 를 처음 接했다. 콕스는 소프트웨어 設計와 프로그래밍에 있어서 再使用性의 問題에 興味를 느끼게 되었고, 스몰토크 같은 프로그래밍 言語가 ITT 시스템 開發者들이 開發을 進行할 强力한 環境을 만드는 데 必要不可缺한 要素임을 깨닫게 되었다. 콕스는 C 컴파일러를 고쳐 스몰토크 의 機能 一部를 追加하기 始作했고, 곧 그 스스로 OOPC라고 불렀던 C의 客體 志向 버전을 내놓게 되었다. 한便 러브는 1982年에 슐럼버거 리서치(Schlumberger Research)에 採用되었고, 스몰토크-80의 最初 商業的 버전을 써 볼 機會를 얻었다. 스몰토크-80은 以後 오브젝티브-C의 成長에 큰 影響을 끼쳤다.

새로운 言語가 가질 實質的인 波及力을 證明하기 위해, 콕스는 旣存 툴에 몇 가지 些少한 변경만 加하면 再使用이 可能한 소프트웨어 컴포넌트를 만들 수 있음을 試演해보였다. 特히 컴포넌트들은 客體를 柔軟하게 支援해야 했고, 라이브러리들과 함께 提供되어야 했으며, 코드 (그리고 그 코드가 必要로 하는 資源들)는 하나의 單一한 플랫폼-中立的 포맷으로 貯藏될 수 있어야 했다.

結局 콕스와 러브는 프로덕티비티 프로덕츠 인터네셔널(Productivity Products International; PPI)이라는 새로운 벤처 會社를 設立한다. 目的은 오브젝티브-C 컴파일러와 强力한 클래스 라이브러리를 結合한 商業 製品을 만들어 파는 것이었다.

1986年에 콕스는 오브젝티브-C의 明細를 담은 冊 "客體 志向 프로그래밍"(Object-Oriented Programming, An Evolutionary Approach)를 出刊한다. 이 冊에서 그는 再使用性의 問題가 單純히 言語 次元의 問題가 아님을 指摘하였으나, 以後 오브젝티브-C는 種種 다른 言語와 機能的으로 比較되고는 했다.

NeXT로 人氣를 얻다 [ 編輯 ]

스티브 잡스 애플 을 떠난 後, 넥스트 라는 會社를 設立한다. 1988年, 넥스트는 스텝스톤(StepStone; 앞에서 말한 PPI 會社의 새로운 이름이며, 오브젝티브-C의 商標權者이다.)에게 오브젝티브-C의 使用 許可를 받고, 오브젝티브-C를 支援하기 위하여 GCC 컴파일러를 擴張시키고 나서, 넥스트스텝 使用者 인터페이스와 인터페이스 빌더 (Interface Builder)를 構築하는 데 쓰일 앱키트(AppKit)와 파운데이션 키트(Foundation Kit)를 開發했다. 비록 넥스트가 내놓은 워크스테이션들은 市場에 强力한 影響力을 行使하지는 못했지만, 그 툴들만큼은 業界에 널리 퍼지게 되었다. 結局 넥스트는 하드웨어 製作을 抛棄하고 소프트웨어 툴들에 集中하기로 方向을 旋回하여 넥스트스텝 (그리고 오픈스텝 (OpenStep))을 獨立的인 使用者 프로그래밍 環境으로 販賣하기 始作했다.

이 때 넥스트스텝 의 無料버전을 構築하려는 프로젝트가 GNU 에서 始作되었는데, 그 이름은 그누스텝 (GNUstep)이었으며, 오픈스텝 標準에 바탕을 둔 것이었다. 1992年 데니스 글래팅(Dennis Glatting)李 GNU 오브젝티브-C의 런타임을 처음으로 作成했다. 1993年 以後로는 크레스텐 크랩 토룹(Kresten Krab Thorup)李 덴마크에서 大學生 時節에 만든 런타임이 널리 쓰였다. 토룹 또한 1993年부터 1996年까지 넥스트에서 일했다.

1996年에 넥스트는 애플 에 合倂되었다. 애플 오픈스텝 을 基盤으로 맥 OS X 라는 새로운 運營 體制 를 내놓는다. 이 안에는 오브젝티브-C와, 넥스트의 오브젝티브-C 基盤 開發 툴들이 包含되어 있었다. 프로젝트 빌더(Project Builder) (나중에 엑스코드 (Xcode)라는 이름으로 바뀐다)라는 開發環境이 提供되었고, 인터페이스 빌더 라는 인터페이스 設計 툴이 提供되었다. 오늘날 애플의 Cocoa API 大部分은 오픈스텝 인터페이스 客體에 基盤을 둔 것이며, 아마 이것이 現存하는 오브젝티브-C 開發 環境 中 가장 널리 쓰이면서도 重要한 것일 것이다.

文法 [ 編輯 ]

오브젝티브-C는 C 위에 덮인 얇은 層이라 볼 수 있다. 오브젝티브-C는 C++ 와 달리 C 言語의 嚴格한 上位集合이다. 嚴格한 上位集合이라는 말은 모든 C프로그램은 다 오브젝티브-C로 컴파일 可能하며, 프로그램의 意味도 兩 言語가 同一하다는 意味이다. 오브젝티브-C는 C 言語와 스몰토크 兩쪽에서 由來한 文法을 使用하고 있다. 前處理(preprocessing), 表記(expressions), 函數 宣言(function declarations), 그리고 函數 呼出(function calls) 等과 같은 大部分의 文法은 C에서 相續된 것이며, 客體 志向的인 機能들은 스몰토크 方式의 메시지 傳達을 통해서 具現되었다.

C++와는 달리 多重相續을 支援하지 않으며, 그 代身 자바 의 인터페이스에 該當하는 프로토콜(protocol)을 定義할 수 있다. 또한 카테고리(category)를 通해 旣存 클래스에 새로운 메쏘드를 追加함으로써 클래스의 機能을 擴張할 수 있다. 이는 相續을 통해서만 機能을 擴張할 수 있는 大多數의 客體 志向 言語와 크게 區別되는 特性이다. C++나 자바 等과는 달리 客體에 對해서 完全한 動的 兄 變換(dynamic typing)을 支援한다.

메시지 [ 編輯 ]

메시지는 客體 志向 프로그래밍 을 支援하기 위해 內部的으로 追加된 文法이다. 오브젝티브-C의 客體 志向 프로그래밍에 對한 모델로 메시지를 客體에 傳達하는 方式을 採用하고 있다. 이는 스몰토크와 매우 類似한 모델이다. 하지만 이는 C++와 다른 言語에서 使用하는 時뮬라 (Simula) 프로그래밍 모델과는 區別되는 것이다. 이러한 特徵은 重要한 意味를 갖는다. 오브젝티브-C의 基本的인 差異點은 메소드를 呼出 하는 것이 아니라 메시지를 傳達 한다는 것이다.

doSomething 이라는 메서드를 갖는 클래스로부터 obj 라는 個體가 具現된다면 이는 메시지 doSomething 에 對해서 "應答"하는 것이다. C++에서는 doSomething 메시지를 obj 로 보내는 行爲는 다음과 같은 코드를 必要로 할 것이다:

obj
.
doSomething
();

오브젝티브-C에서는 다음과 같이 쓰인다:

[
obj
 doSomething
];

오브젝티브-C는 動的 兄 變換을 使用한다. 이는 모든 메소드가 辭典에 正義되어야만 呼出이 可能한 C++이나 자바와 같은 靜寂·明示的 刑 變換을 使用하는 言語와 다른 點이다.

C++ 과 다르게 假想函數의 宣言없이 자바 와 같이 子息클래스에서 메소드를 오버라이딩 하는 것만으로 多形性이 提供된다.

클래스의 宣言과 具現 [ 編輯 ]

C++와 비슷하게 클래스의 宣言과 具現은 헤더파일과 소스파일로 나뉜다. 헤더파일의 擴張字는 .h로 同一하나 소스파일의 擴張字는 .c나 .cpp가 아닌 .m(.c 에 對應) 또는 .mm(.cpp 에 對應)이다. 擴張字가 .m 또는 .mm으로 定해진 理由는 但只 .o와 .c가 C에 依해 使用되고 있었기 때문이다. [2]

宣言(Interface) [ 編輯 ]

宣言(interface)은 클래스의 基本的인 構造를 列擧하는 것이며, 一般的으로 헤더파일 .h에 記錄된다.

@interface
 classname
 : 
superclassname
 // 父母클래스 이름

{

    // 클래스 變數

}

+
 classMethod1
;
 // 클래스 메소드

+
 (
return_type
)
classMethod2
;

+
 (
return_type
)
classMethod3:
(
param1_type
)
param1_varName
;


-
 (
return_type
)
instanceMethod1:
(
param1_type
)
param1_varName
 :
(
param2_type
)
param2_varName
;
 // 인스턴스 메소드

-
 (
return_type
)
instanceMethod2WithParameter:
(
param1_type
)
param1_varName
 andOtherParameter:
(
param2_type
)
param2_varName
;

@end

클래스의 宣言은 @interface로 始作하고 @end로 끝난다. +記號는 클래스 메소드를 뜻한다. 자바 의 政敵메소드와 同一하며, 宣言된 클래스의 인스턴스의 有無에 相關없이 恒常 存在한다. 클래스 메소드는 클래스 變數에 對한 接近權限이 없다. -記號는 인스턴스 메소드이며 클래스가 인스턴스畫家 되어야만 使用할 수 있다.

메소드에 媒介變數가 있을 境遇 一般的인 프로그래밍 言語와 다르게 括弧代身 콜론으로 區分한다. 變數가 2個 以上일 境遇 그 該當 變數가 무슨 役割을 하는지 라벨을 따로 붙여준다. 이 레이블은 코드를 더 읽기 쉽게 도와준다.

-
 (
void
)
setRangeStart:
(
int
)
start
 end:
(
int
)
end
;

-
 (
void
)
setWithLatename:
(
NSString
 *
)
last
 firstname:
(
NSString
 *
)
first
 middlename:
(
NSString
 *
)
middle
;

實際 코드 上에선 다음과 같이 呼出된다.

[
setRangeStart
:
4
 end
:
10
];

[
setWithLatename
:
@"Last"
 firstname
:
@"First"
 middlename
:
@"Middle"
];

具現(Implementation) [ 編輯 ]

@implementation
 classname

+
 (
return_type
)
classMethod

{

    // 具現

}

-
 (
return_type
)
instanceMethod

{

    // 具現

}

@end

클래스의 具現은 @implementation으로 始作하고 @end로 끝난다. 클래스 變數를 다시 적을 必要는 없고, 宣言한 메소드의 구현만 하면된다.

프로토콜(Protocols) [ 編輯 ]

NeXT 는 오브젝티브-C에 多重 相續 을 스펙(specification)에 導入하기 위하여 擴張하였지만, 그러나 具現(implementation)하지는 못 했으며, 團地 프로토콜 灣을 導入했다. 이것은 C++ 에서 抽象的으로 多重 相續되는 基本 클래스 또는 자바 (프로그래밍 言語) C# 에서 "인터페이스(interface)"를 成就하기 위한 패턴이다. 오브젝티브-C는 非公式 프로토콜(informal protocol)이라고 불리는 ad-hoc 프로토콜과, 公式 프로토콜이라고 불리는 컴파일러가 强制하는 프토토콜을 통해 多衆 相續과 類似한 機能을 하도록 만들 수 있다. 參考로 後에 開發된 자바 (프로그래밍 言語) 의 境遇에도 多衆 相續을 支援하지 않고 인터페이스라는 이름으로 오브젝티브-C의 프로토콜의 槪念을 使用한다. [3]

非公式 프로토콜(Informal protocols)은 클래스가 具現할 수 있는 메소드의 리스트이다. 클래스가 具現하기 위하여 選擇한 메소드 리스트이다. 이것은 그 文書에 明細 되어 있는데, 왜냐하면 言語 안에는 그 리스트를 表現하기 위한 文法이 없기 때문이다. 非公式 프로토콜은 種種 選擇的 메소드(optional method)를 包含하는데, 이 메소드가 具現되면, 클래스의 動作(behavior)李 바뀔 수 있기 때문이다. 例를 들어, 텍스트 필드 클래스는 유저가 타이핑한 글을 自動 完成 機能(auto-complete feature)을 遂行하기 위한 選擇的 메소드를 가진 非公式 프로토콜 具現하기 위한 代理者 를 가질 수 있다. 그 텍스트 필드는 그 委任이 그 메소드를 ( 反映 (컴퓨터 科學) (Reflection)을 通해서) 具現되며, 그것이 분명하면, 自動 完成 機能을 支援하기 위하여 그 委任된 메소드를 呼出한다.

公式 프로토콜(formal protocol)은 자바와 C#의 인터페이스와는 類似하다. 이 프로토콜은 어떤 클래스가 메소드들을 具現하기 하기 위한 리스트이다. 오브젝티브-C 2.0 以前 버전들에서는 클래스는 그 自身 스스로 採擇하여 宣言하고 있는 프로토콜 안에 들어 있는 모든 메소드를 具現해야 한다고 要求하고 있다; 反面에 컴파일러는 萬若 그 클래스에서 宣言된 프로토콜이 가지고 있는 모든 메소드가 具現되지 않았다면 에러를 省略할 것이다. 오브젝티브-C 2.0은 프로토콜 안에 있는 特定 메소드가 選擇的(optional)이라고 標示하기 위한 支援을 追加했으며, 컴파일러는 選擇的(optional) 메소드들을 强制로 具現하지 않을 것이다.

오브젝티브-C이 가지고 있는 프로토콜(protocols) 槪念은 자바 C# 의 인터페이스와는 좀 다르다. 왜냐하면 클래스를 具現할 때, 特定 프로토콜을 具現하도록 宣言하지 않아도 그 프로토콜을 具現해 버릴 수 있기 때문이다. 그 差異는 外部 코드에서는 알아챌 수 없다. 公式 프로토콜은 어떤 具現도 提供할 수 없으며, 單純히 특정한 프로토콜을 滿足하는 클래스는 該當 프로토콜에 屬한 모든 메소드를 具現해야 한다는 것을 强制하기 위해 쓰인다. 넥스트/애플 라이브러리에서, 프로토콜은 分散 客體 시스템(Distributed Objects system)에서 어떤 遠隔 시스템에서 일하는 客體의 能力을 表現하기 위하여 자주 使用된다.

口文

@protocol Locking
- (void)lock;
- (void)unlock;
@end

이것은 락을 걸고 푼다는 抽象 아이디어를 明示하고 있다. 클래스를 定義할 때에는 다음과 같이 쓴다.

@interface
 SomeClass
 : 
SomeSuperClass
 <
Locking
>

@end

SomeClass에 依해 만들어진 客體들은 Locking 프로토콜에 明示된 두 個의 인스턴스 메소드의 具現을 提供할 것임을 明示하고 있다. 一例로 이런 抽象化된 名稅法은 具現 階層(hierarchy)李 어떻게 만들어져야하는지를 指定하지 않더라도 플러그인에 要求되는 行爲 形態를 記述할 수 있어서 特히 效果的이다.

헬로 월드 프로그램 [ 編輯 ]

#import <Foundation/Foundation.h>


int
 main
 (
int
 argc
,
 const
 char
 *
 argv
[])
 {

    NSAutoreleasePool
 *
 pool
 =
 [[
NSAutoreleasePool
 alloc
]
 init
];
  //AutoreleasePool을 割當하고 初期化


    NSString
 *
helloWorldStr
 =
 [
NSString
 stringWithString
:
@"Hello World!"
];
 // helloWorldStr에 "Hello World!" 大入

    NSLog
(
@"%@"
,
helloWorldStr
);
 // 出力

    [
pool
 drain
];
  //AutoreleasePool Drain

    return
 0
;

}

// 最近의 文法 變更으로 쉬워짐

#import <Foundation/Foundation.h>


int
 main
 (
int
 argc
,
 const
 char
 *
 argv
[])
 {

    @
AutoreleasePool
 //AutoreleasePool을 割當하고 初期化


    NSLog
(
@"  Hello World"
);

    return
 0
;

}

이 프로그램은 標準 콘솔 出力으로 Hello World! 를 出力한다. 元來 6, 7番째 줄을 NSLog(@"Hello World!"); 로 바꾸어도 同一하게 動作하지만, C와, 오브젝티브-C의 다른 點을 보여주기 위해 NSString型의 helloWorldStr 變數를 利用하여 表現하였다.

變種 [ 編輯 ]

오브젝티브-C++ [ 編輯 ]

오브젝티브-C++은 GNU 컴파일러 모음 (GCC)과 클랭 에 對한 프론트엔드가 受容하는 言語 變種이다. C++와 오브젝티브-C 文法의 母音을 利用하는 소스 파일을 컴파일할 수 있다. 오브젝티브-C++는 C++에 오브젝티브-C의 C 追加 擴張 機能을 包含시킨다.

오브젝티브-C 2.0 [ 編輯 ]

2006年 世界 開發者 會議 에서 애플은 "現代的인 가비지 콜렉션, 文法 機能 向上 [4] , 런타임 性能 改善 [5] , 64비트 支援"을 包含하는, 오브젝티브-C 言語의 里비전으로서 오브젝티브 C-2.0 公開를 發表하였다.

같이 보기 [ 編輯 ]

各州 [ 編輯 ]

  1. “Runtime Versions and Platforms” . 《Developer.apple.com》. 2016年 7月 20日에 原本 文書 에서 保存된 文書 . 2017年 12月 24日에 確認함 .  
  2. Why do Objective C files use the .m extension? , 오브젝티브-C의 開發者인 Brad Cox의 答辯.
  3. 181쪽, 誤記하라 타케시 (2009-07-023). 《objective - C: 맥과 아이폰 애플리케이션 프로그래밍》. 한빛미디어(週). ISBN   978-89-7914-683-7 13560 |isbn= 값 確認 必要: length ( 도움말 ) .  
  4. “Objective-C 2.0: more clues” . Lists.apple.com. 2006年 8月 10日. 2009年 6月 18日에 原本 文書 에서 保存된 文書 . 2010年 5月 30日에 確認함 .  
  5. “Re: Objective-C 2.0” . Lists.apple.com. 2010年 11月 24日에 原本 文書 에서 保存된 文書 . 2010年 5月 30日에 確認함 .  

外部 링크 [ 編輯 ]