[Note] Effective OC - Item 1~3

Chapter 1. Accustoming Yourself to Objective-C

Item1: Familiarize Yourself With Objective-C’s Roots
이 절의 개편에서는 메사징 스트루처 vs. Function calling의 차이점을 언급했다.글에서 제시한 차이점은 다음과 같다.
Messaging structure: runtime에서 어떤 방법을 실행할지 결정할 수 있습니다.메시지 수신 대상 문제 포함.Function calling: 컴파일러가 호출 방법을 결정합니다.
메시지 structure에 대해 OC 동태적 특징의 집중적인 표현으로서 공식적인 Runtime Programming Guide에서 비교적 상세한 설명을 했다.간단한 과정 설명은 다음과 같다. 런타임, 메시지, 방법과 연결되는 것이다.메시지 expression이 objc 로 바뀝니다.msgSend (c 언어 메시지 방법), 이 함수는 방법의 selector 주소,receiver 및 기타 정보를 전달하여 동적 귀속에 사용합니다.구체적인 과정은 세 단계로 나뉜다. 첫 번째 단계는 호출할 selector를 찾는 것이다.대상의isa pointer를 이용하여 하위 클래스에서 부모 클래스로 찾습니다.두 번째, 찾은 후에 호출할 수 있습니다.receiver와 selector는 hidden argument로 전송됩니다.세 번째 단계,returnvalue.또한 호출 후 selector를cache에 저장하여 효율을 높일 수 있습니다.
runtime는 넓고 심오하며, 실천한 적이 없고, 체득이 깊지 않다(:з」∠)_
이 편은 변수의 저장을 언급한 김에 총결산을 하였다.
먼저 C에서 데이터를 저장하는 데이터 segment:

코드 저장: 코드 저장

BSS(Block Started by Symbols)segment: 초기화된 글로벌 var과 static var

저장

Stack Segment: local var

Heap Segment: 일반적으로 모든 oc object는 무더기에 분배됩니다.

Data Segment: 초기화되지 않은 글로벌 var 및 static var

또한 모든segment에는 constant을 저장하는 데 사용되는 write protected region이 있습니다.평소에 흔히 생각하는 것은 Stack과 Heap이다.heap에 분배된 메모리는 직접 관리해야 합니다. stack에서 변수를 저장하는 메모리는 창고 프레임이 팝업될 때 자동으로 정리됩니다.
변수에 대해 말하자면 분배가 어디에 있는지는 글로벌/local뿐만 아니라static/const를 보고 구체적인 위치를 결정해야 한다.그리고 컴파일러는 구체적인 상황에 따라 최적화를 할 수도 있다.일반적으로: local variable: auto 또는 static에 따라 다릅니다. 전자는 stack에 있고 후자는 데이터 segment에 있습니다.global\static\extern variable: data segment/BSS const variable: auto 또는 static에 따라 전자는 stack, 후자는 read only data segment.
조금 특별한 경우: Block은 창고에 분배되며, Block을 통해copy () 는 그것을 더미에 복사합니다.NSString은 데이터 segment에 분산되어 있는 특수한 제품입니다.그러나 리턴/release 등 메모리 관리는 필요 없고 NSCFConstantString 하위 클래스는 모든 과정을 최적화시켜 자동으로 도와줍니다.
Item 2: Minimize Importing Headers in Headers
이 편의 중심 사상은 첫 번째 문건을 도입할 시기를 최대한 늦추는 것이다.forward declaring이란 #import을 사용하지 않고 @class를 사용하는 것입니다.차이점:

#import은 헤더 파일 전체를 도입합니다.이 헤더 파일 자체에 도입된 다른 헤더 파일을 포함합니다.

@class는 컴파일러에게 특정한 클래스의 존재를 알릴 뿐 이 클래스의 다른 정보는 포함되지 않습니다.

이 문서에서는 forward declaring을 사용하는 장점을 제시했다.

번역 시간을 줄인다.

각 헤더 파일이 상대방의 헤더 파일을 도입하면 컴파일러가 컴파일할 때 사순환에 빠질 수 있다(#include를 사용한다면).

#import을 사용하면 데드 사이클이 발생하지 않습니다.여기에는 #import과 #include의 차이점도 관련되어 있습니다.

#include는 가져온 줄을 파일 내용으로 직접 대체합니다.매우 강직하다.그러나 중복 정의, 사순환 등 문제를 일으킬 수도 있다.이러한 문제를 피하려면 도입할 때include guards를 써야 한다. 바로 #infdef 문장이다. 비교적 번거롭고 여러 가지 상황을 고려해야 한다.

#import은 OC가 #include를 바탕으로 한 최적화입니다(감사합니다!),관련 서류는 한 번만 도입되기 때문에 사순환 문제가 없을 것이라고 보증했다.그러나 두 종류가 서로 상대방을 인용하면 그 중 하나가 정확하게 번역되지 못할 수도 있다.

또한 본 편에서는 협의 도입에 대한 추천 처리 방법을 언급했다.
프로토콜에 대해서는 가능한 한 class-continuation category에 넣으세요.그렇지 않으면 한 개의 머리 파일에 따로 놓고 도입하는 것이 가장 좋다.
Item 3: Prefer Literal Syntax over the Equivalent Methods
이 편은 비교적 간단하지만, 중심 사상은 Literal Syntax를 사용할 수 있다면 전력을 다해 쓰십시오!주로 Foundation 프레임워크의 NSString, NSNumber, NSArray, NSDictionary 클래스를 대상으로 한다.Literal Syntax 역시 일반적인 alloc init 또는 클래스 초기화 방법과 다르게 생긴 초기화 구문을 흔히 볼 수 있습니다.위에서 언급한 클래스에 대응하는literal syntax 형식의 초기화는 다음과 같습니다.

NSString *myString = @“23333”;
NSNumber *myNumber = @233;
NSNumber *myFloatNumber = @2.3333f;
NSArray *myArray = @[@2, @3, @3, @3, @3];
NSDictionary *myDictionary = @{@“key1”: @“obj1”,
     @“key2”: @“obj2”};

또한 그룹 탭을 떼어내는 작업은 ObjectAtIndex: 방법이 아닌 myArray[0]를 추천합니다.사전 액세스에는 objectForKey: 메서드가 아닌 myDictionary [@ "key1"]을 사용하는 것이 좋습니다.literal sytax를 사용하여 작성된 객체는 변경될 수 없습니다.mutableCopy를 통해 가변 버전을 얻을 수 있습니다.NSMutableArray *mutableArray = [@[@2, @3, @3, @3, @3] mutableCopy];
장점: 더 안전!만약 그룹이나 사전에 nil이 함유되어 있다면, 이상을 던져서 검사하기 편할 것입니다.제한: 문자열을 제외하고 작성된 객체는 Foundation 프레임에 속해야 합니다.이런 종류의 자류도 안 된다.물론 일반적으로 이런 기본 클래스를 만드는 하위 클래스도 추천하지 않는다.