[iOS프로그래밍] Cocoa Architecture

[edit] Cocoa history

Cocoa is derived from the NeXTSTEP and OPENSTEP programming environments developed by NeXT in the late 1980s. Apple acquired NeXT in December 1996, and subsequently went to work on the Rhapsody operating system that was supposed to be the direct successor of OPENSTEP. It was to have an emulation base for Mac OS applications, called Blue Box. The OPENSTEP base of libraries and binary support was termed Yellow Box. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. As a result, Cocoa classes begin with the acronym "NS" (standing either for the NeXT-Sun creation of OPENSTEP, or for the original proprietary term for the OPENSTEP framework, NeXTSTEP^[1]): NSString, NSArray, etc.

Much of the work that went into developing OPENSTEP was applied to the development of Mac OS X, Cocoa being the most visible part. There are, however, some differences. For example, NeXTSTEP and OPENSTEP used Display PostScript for on-screen display of text and graphics, while Cocoa depends on Apple's Quartz (which uses the PDF imaging model). Cocoa also has a level of Internet support, including the NSURL and WebKit HTML classes, and others, while under OPENSTEP there was only rudimentary support for managed network connections through NSFileHandle classes and Berkeley sockets.

Prior to its current use, the "Cocoa" trademark was the name of an application that allowed children to create multimedia projects. It was originally known as KidSim, and is now licensed to a third party and marketed as Stagecast Creator. The program was discontinued in one of the rationalizations that followed Steve Jobs' return to Apple. The name was re-used to avoid the delay while registering a new trademark, with Stagecast agreeing to market the older Cocoa under a new name. Cocoa is believed to stand for "Core Objective-C Object Architecture", although this is certainly a backronym.

[edit] Memory management

One feature of the Cocoa environment is its facility for managing dynamically allocated memory. Cocoa's NSObject class, from which most classes, both vendor and user, are derived, implements a reference counting scheme for memory management. Objects derived from the NSObject root class respond to a retain and a release message and keep a retain count which can be queried by sending a retainCount message. A newly allocated object created with alloc or copy has a retain count of one. Sending that object a retain message increments the retain count, while sending it a release message decrements the retain count. When an object's retain count reaches zero, it is deallocated, its memory freed. (Deallocation is to Objective-C objects as destruction is to C++ objects. The dealloc method is functionally similar to a C++ destructor. dealloc is not guaranteed to be invoked.) This reference counting approach is very similar to that of Microsoft's COM which features the IUnknowninterface. IUnknown provides equivalents to retain and release in the form of AddRef and Release.

 코코아 환경의 한 특징은 동적으로 할당된 메모리를 관리하기위한 시설입니다. 대부분의 수업, 공급 업체와 사용자 모두가, 파생되고있는 코코아의 NSObject 클래스는 메모리 관리를위한 체계를 계산 참조를 구현합니다.NSObject 루트 클래스에서 파생된 개체유지와 릴리스 메시지 회신 및 retainCount 메시지를 보냄으로써 질의를 할수 유지 카운트를 유지. alloc 또는 복사하여 만든 새롭게 할당된 객체는 하나의 유지 카운트가 있습니다. 카운트를 유지 그것을 릴리스 메시지 감소를 보내는 동안 유지 메시지 증가, 카운트를 유지 해당 개체 보내기.개체의 유지 카운트가 제로에 도달하면, 그것은deallocated되고, 그 메모리를 해제. (파괴는 C + + 개체이므로 Deallocation이 목표-C개체입니다. dealloc 메서드에 기능적으로 유사하다 C + + 소멸자. dealloc이 호출되도록 보장되지 않습니다.) 접근법을 계산이 참조는 기능이 Microsoft의 COM의 그것과 매우 유사하다 IUnknowninterface. IUnknown은 보유 및 AddRef 및 릴리스 형태로 출시될상응을 제공합니다.

 - 코코아는 동적으로 메모리를 관리합니다. 
이하 여기서 알아야 할 것이 NSObject라는 루트 클래스이겠네요. 

(1) 루트 클래스의 역할

Objective-C 는 객체가 가지는 동적인 특징을 구현하기 위해

실행 시에 런타임 시스템(runtime system)의 도움을 받습니다.

(줄여서 런타임이라고 부르기도 합니다.)

이 런타임 시스템은 Objective-C 를 위한 운영체제와 같은 것으로

객체의 생성, 해제를 수반하는 메모리 영역의 관리나

송신된 메시지에 대응하는 메소드 탐색 등을 해줍니다.

일반적으로 런타임 시스템의 기능을 개발자가

프로그램에서 집적 사용하는 경우는 거의 없습니다.

이러한 기본적인 기능들은 루트 클래스인 NSObject 에서

메소드의 형태로 제공되어집니다.

NSObject를 상속한 모든 클래스는 상속받은 기능을 사용해서

런타임 시스템의 기능을 의식하지 않고 이용할 수 있습니다.

말하자면 루트 클래스는 런타임 시스템에 대해 인터페이스 역할을 하는 셈입니다.

Cocoa 는 NeXT 의 OPENSTEP 의 주요 API 를 계승, 발전시킨 것이라고 말할 수 있는데

OPENSTEP 은 이전에 NeXTstep 이라고 불렸습니다.

NeXTstep 시절에 루트 클래스는 Object라고 하는 클래스였지만,

OPENSTEP 이 된 후로는 NSObject로 변경되어 동시에 클래스 설계 방침도 대폭 변경되었습니다.

(Cocoa 클래스에서 접두어로 사용되는 NS... 는 NeXTstep 에서 유래한 것입니다.)

(2) 클래스와 인스턴스

 NSObject 는 인스턴스 변수를 하나만 가집니다.

이것은 isa 라는 Class 타입의 변수입니다.

모든 인스턴스 객체는 이 isa 에 의해

자신이 속한 클래스 객체를 참조하고 있습니다.

isa 는 인스턴스와 클래스의 관계를 결정하는

상당히 중요한 변수로 서브 클래스에서 변경해서는 안됩니다.

또 인스턴스가 속한 클래스를 확인하기 위해서는 isa 를 참조하지 않고

인스턴스 메소드인 class 를 사용해야 합니다.

이제 클래스와 인스턴스에 관련된 메소드들을 설명합니다.

NSObject 의 메소드는 NSObject 자체에서 사용하기도 하지만,

그 서브 클래스인 여러 클래스와 인스턴스에서 

공통으로도 사용한다는 것을 유념하기 바랍니다.

- (Class) class	리시버가 속하는 클래스의 클래스 객체를 리턴합니다.
+ (Class) class	클래스 객체를 리턴합니다. 클래스 메소드를 호출할 때는 클래스 명을 메시지 리시버로 사용합니다.
- (id) self	리시버 자체를 리턴합니다.
- (BOOL) isMemberOfClass: (Class) aClass	리시버가 인수로 넘어온 클래스의 인스턴스인지 확인합니다.
- (BOOL) isKindOfClass: (Class) aClass	리시버가 인수의 인스턴스인지 혹은 그 클래스의 서브 클래스인지 확인합니다. 이 메소드가 isMemberOfClass: 와 다른 점은 인수의 클래스 뿐만 아니라, 그 서브 클래스의 인스턴스인 경우에도 YES 를 리턴한다는 것입니다.
+ (BOOL) isSubclassOfClass: (Class) aClass	해당 클래스가 인수로 넘어온 클래스의 서브 클래스이거나 같은 클래스인 경우 YES 를 리턴합니다.
- (Class) superclass	리시버가 속하는 클래스의 슈퍼 클래스 객체를 리턴합니다.
+ (Class) superclass	해당 클래스의 슈퍼 클래스 객체를 리턴합니다.

(3) 인스턴스 생성과 해제

+ (id) alloc	리시버로 지정된 클래스의 인스턴스를 생성합니다. 생성된 인스턴스의 초기화를 완전히 수행하기 위해 통상적으로 init 혹은 init... 로 시작하는 이니셜라이저와 조합해서 이용할 필요가 있습니다. 서브 클래스에서 alloc 을 오버라이드하면 안됩니다.
- (void) dealloc	인스턴스를 해제합니다. 이 메소드는 release 결과로 호출됩니다. 서브 클래스에서 dealloc 을 오버라이드 하는 경우를 제외하면 개발자가 프로그램에서 집적 호출할 일은 없습니다.
- (oneway void) release	리시버의 레퍼런스 카운트를 하나 감소시킵니다. 레퍼런스 카운트가 0이 되면 dealloc 메소드가 호출되어 리시버가 해제됩니다.
- (id) retain	리시버의 레퍼런스 카운트를 하나 증가시키고, 리시버 자체를 리턴합니다.
- (id) autorelease	리시버를 현재 유효한 자동 해제 풀에 추가하고 리시버 자체를 리턴합니다.
- (NSUInteger) retainCount	리시버의 레퍼런스 카운트 값을 리턴하고, 보통 디버그 용도로 사용되어집니다.
- (void) finalize	가비지 컬렉터가 리시버를 해제하기 직전에 실행됩니다. 아이폰 프로그래밍을 위해서 Objective-C 를 공부하고 있다면 아직까지는 사용할 일이 없는 메소드입니다.

(4) 초기화

- (id) init	alloc 으로 생성된 인스턴스를 초기화 합니다. 서브 클래스에서는 init 을 오버라이드하거나 새로운 이니셜라이저를 init... 이란 이름으로 정의해서 초기화 합니다.
+ (void) initialize	클래스 객체의 초기화, 즉 클래스 내에서 공통으로 사용되는 변수의 초기 설정을 하기 위해 사용합니다. 이 메소드는 그 클래스에 대해 보내지는 첫 메시지보다 먼저 실행되고, 프로그램에서 집적 호출하면 안됩니다.
+ (id) new	대부분의 경우 alloc 과 init 의 호출을 조합한 것과 같습니다. new 메소드로 리턴되는 인스턴스의 오너는 호출한 쪽의 객체입니다. 단, alloc과 init의 조합으로 new를 수정해서 정의하는 이점은 거의 없습니다.     한편 클래스에 따라서는 alloc 으로 매번 새로운 인스턴스를 생성하지 않고, 이미 생성한 인스턴스를 풀에 두고 재사용하는 것처럼 같은 값을 가진 인스턴스를 공유하는 구조가 필요한 경우가 있습니다. 이런 경우 new 메소드 혹은 new...로 시작하는 메소드를 사용할 수 있습니다.

(5) 객체의 비교와 객체의 내용 기술

- (BOOL) isEqual: (id) anObject	리시버와 인수 anObject가 같다고 판단될 경우 YES를 리턴합니다. 원칙적으로 같은 id값, 즉 객체를 가리키는 포인터가 같으면 같은 객체라고 판단합니다. 서브 클래스에서는 여기에 추가해서 같은 값을 가질 경우 같다고 판단하도록 정의를 확장할 수 있습니다. 비교를 위한 메소드로 compare: 나 isEqualTo... 과 같이 그 클래스 특유의 비교 메소드를 가지는 것도 있습니다.
+ (NSString *) description	리시버의 클래스 내용을 표시하는 NSString 문자열을 리턴합니다. 일반적으로 리턴 값은 클래스의 이름입니다.
- (NSString *) description	리시버의 인스턴스 객체의 내용을 표시하는 NSString 문자열을 리턴합니다. 보통은 클래스 명과 id 값을 표시하는데 서브 클래스에 따라 독자적인 정의를 사용하는 경우도 있습니다.

[출처] 09. NSObject 클래스|작성자 Son Of Grace

In addition to manual reference counting, application programmers may choose to make use of autorelease pools. Sending an object an autorelease message registers a future release with that thread's nearest autorelease pool. When the autorelease pool is itself released, it sends a corresponding release message for every registered autorelease. Autorelease pools are generally created and released at the beginning and end of the event loop, guaranteeing program flow has passed out of the block where objects were autoreleased. This means the application has predictable performance and memory collection is generally invisible to the user, whereas under most fully automated schemes the application will sometimes suddenly stop responding when the garbage collection system is started.

Automatic garbage collection for Cocoa is also supported starting with Objective-C 2.0, using Xcode 3.0 which is included withMac OS X 10.5 Leopard. The programmer now has the choice of whether to manually manage memory of objects or not. Opinions on this are divided. Some say that reference counting is superior because it allows the programmer to have precise control over when objects are deallocated, but does not add the burden of doing so for every object a program allocates, nor incur the performance penalty usually associated with automatic garbage collection. Others say the entire scheme is unnecessary, that Java-style automatic garbage collection is superior, because it significantly reduces the possibility of programmer error in memory management. Cocoa garbage collection is fully backwards compatible; it is only used if the project settings are modified to take advantage of it. Furthermore, garbage collection can be turned on or off at different points in the program.

[edit] Main frameworks

Cocoa consists primarily of two Objective-C object libraries called frameworks. Frameworks are functionally similar to shared libraries, a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation.

• Foundation Kit, or more commonly simply Foundation, first appeared in OpenStep. On Mac OS X, it is based on Core Foundation. Foundation is a generic object-oriented library providing string and value manipulation, containers and iteration,distributed computing, run loops, and other functions that are not directly tied to the graphical user interface. The "NS" prefix, used for all classes and constants in the framework, comes from Cocoa's NeXTSTEP heritage.
• Application Kit or AppKit is directly descended from the original NeXTSTEP Application Kit. It contains code with which programs can create and interact with graphical user interfaces. AppKit is built on top of Foundation, and uses the same "NS" prefix.

A key part of the Cocoa architecture is its comprehensive views model. This is organized along conventional lines for an application framework, but is based on the PDF drawing model provided by Quartz. This allows creation of custom drawing content using PostScript-like drawing commands, which also allow automatic printer support and so forth. Since the Cocoa framework manages all the clipping, scrolling, scaling and other chores of drawing graphics, the programmer is freed from implementing basic infrastructure and can concentrate only on the unique aspects of an application's content.

[edit] Model-view-controller

The Smalltalk teams at Xerox PARC eventually settled on a design philosophy that led to easy development and high code reuse. Known as "model-view-controller" (MVC), the concept breaks an application into three sets of interacting object classes. Model classes represent raw data, such as documents, settings files, or objects in memory. Views are, as the name implies, representations (often visual) of the data. Controller classes contain logic which links the models to their views, and maintains state to keep them synchronized.

Cocoa's design is a strict application of MVC principles. Under OpenStep, most of the classes provided were either high-level View classes (in AppKit) or one of a number of relatively low-level model classes like NSString. Compared to similar MVC systems, OpenStep lacked a strong model layer. There was no stock class which represented a "document," for instance. During the transition to Cocoa, the model layer was expanded greatly, introducing a number of pre-rolled classes to provide functionality common to desktop applications.

In Mac OS X 10.3, Apple introduced the NSController family of classes, which provide predefined behavior for the controller layer. These classes are considered part of the Cocoa Bindings system, which also makes extensive use of protocols such asKey-Value Observing and Key-Value Binding. The term 'binding' refers to a relationship between two objects, often between a view and a controller. Bindings allow the developer to focus more on declarative relationships rather than orchestrating fine-grained behavior.

With the arrival of Mac OS X 10.4, Apple extended this foundation further by introducing the Core Data framework, which standardizes change tracking and persistence in the model layer. In effect, the framework greatly simplifies the process of making changes to application data, undoing changes (if necessary), saving data to disk, and reading it back in.

By providing framework support for all three MVC layers, Apple's goal is to reduce the amount of boilerplate or "glue" code that developers have to write, freeing up resources to spend time on application-specific features.

[edit] Late binding

In most object-oriented languages, calls to methods are represented physically by a pointer to the code in memory. This restricts the design of an application since specific "command handling" classes are required, usually organized according to thechain of command design pattern. While Cocoa retains this approach for the most part, the "late binding" of Objective-C opens up more flexibility.

Under Objective-C, methods are represented by a selector, a string describing the method to be called. When a message is sent, the selector is sent into the ObjC runtime, matched against a list of available methods, and the method's implementationis called. Since the selector is text data, this allows it to be saved to a file, transmitted over a network or between processes, or manipulated in other ways. The implementation of the method is looked up at runtime, not compile time. There is a small performance penalty for this^[2], but late binding allows the same selector to reference different implementations.

By a similar token, Cocoa provides a pervasive data manipulation technique called key-value coding (KVC). This permits a piece of data or property of an object to be looked up or changed at runtime by name — the property name acts as a key to the value itself. In traditional languages, this late binding is not possible. KVC leads to great design flexibility — an object's type does not need to be known, yet any property of that object can be discovered using KVC. In addition, by extending this system using something Cocoa calls Key-Value Observing (KVO), automatic support for Undo/Redo is provided.

[edit] Rich objects

One of the most useful features of Cocoa is the powerful "base objects" the system supplies. As an example, consider the Foundation classes NSString and NSAttributedString, which provide Unicode strings, and the NSText system in AppKit, which allows the programmer to place string objects in the GUI.

NSText and its related classes are used to display and edit strings. The collection of objects involved permit an application to implement anything from a simple single-line text entry field to a complete multi-page, multi-column text layout schema, with full professional typography features such as kerning, ligatures, running text around arbitrary shapes, rotation, full Unicode support and anti-aliased glyph rendering. Paragraph layout can be controlled automatically or by the user, using a built-in "ruler" object that can be attached to any text view. Spell checking is automatic, using a single dictionary used by all applications that uses the "squiggly underlining" introduced by Microsoft (actually a dashed red underline in Cocoa). Unlimited Undo/Redo support is built in. Using only the built-in features, one can write a text editor application in as few as 13 lines of code. With new controller objects, this may fall to zero. This is in contrast to the TextEdit APIs found in the earlier Mac OS.

When extensions are needed, Cocoa's use of Objective-C makes this a straightforward task. Objective-C includes the concept of "categories" which allows for modifications to an existing class "in-place". Functionality can be accomplished in a category without any changes to the original classes in the framework, or even access to its source. Under more common frameworks this same task would require the programmer to make a new subclass supporting the additional features, and then change all instances of the classes to this new class.