대상 C 방법을 언제 정의합니까?

Question

대상 C를 배우고 C/C ++ 배경이 있습니다.

• 객체 지향 C ++에서는 부모 클래스에서 선언 된 경우에도 정의 (구현) 메소드를 항상 선언해야합니다.

• 절차 스타일 C, IIRC에서는 나중에 파일에 나오는 동일한 컴파일 단위 (예 : 동일한 파일)에서 다른 제품에서만 호출되는 한 함수를 정의 할 수 있습니다. "extern"으로 다른 곳에서 선언하지 않습니다).

• 이제 Objective-C에서는 헤더 파일에서 선택기가 외부에서 사용될 경우에만 선언해야하며 .M 파일에서 선택기를 구성하고 내부에 전화 할 수 있습니다. .m 파일. 또한, 대의원 방법 또는 상속 된 방법은 결코 정의되지 않은 것으로 보입니다.

내가 올바른 길을 가고 있습니까? Objective-C에서 언제 선택기를 정의해야합니까?

Answer 1

객관적인 C 방법의 경우, 일반적인 관행은 당신이 노출하려는 방법을 @interface 헤더 파일의 섹션이므로 다른 코드에는 .h 만 포함 할 수 있으며 코드와 상호 작용하는 방법을 알고 있습니다. 주문 기반 "Lazy Declaration"은 C의 함수와 마찬가지로 작동합니다. 해야합니다 순서로 해결할 수없는 종속성이 없다면 메소드 프로토 타입을 선언하지만 내부에 메소드 프로토 타입을 추가 할 수 있습니다. @implementation 필요한 경우.

네, 당신은 올바른 길을 가고 있습니다. 상속 메소드의 메소드 프로토 타입을 반복하지 마십시오. 컴파일러는 부모의 헤더 파일에서 찾습니다. 대의원 방법은 카테고리에서 프로토 타입으로 정의 될 수 있고 (클래스에 태클) 원하는대로 구현 될 수 있지만, 대의원은 이미 정의되어 있으므로 메소드 프로토 타입을 제공 할 필요가 없습니다. (명확성 등을 원한다면 여전히 가능합니다.)

당신은 단지 Objective-C를 배우기 때문에,이 답변의 나머지 부분은 당신이 요청한 것보다 훨씬 더 자세합니다. 당신은 경고를 받았습니다. ;-)

---

정적으로 변수를 입력 할 때 (예 : MyClass* 대신에 id) 컴파일러는 클래스가 클래스가 그것을 구현하는 것을 광고하지 않는 메소드를 호출하려고 할 때 경고합니다. 변수를 동적으로 입력하면 컴파일러가 원하는 것을 호출하는 것을 막지 않으며 존재하지 않는 것을 호출하는 경우 런타임 오류 만 얻을 수 있습니다. 언어에 관한 한, 런타임에 오류가없는 클래스가 구현하는 방법을 호출 할 수 있습니다. 누가 방법을 호출 할 수 있는지 제한 할 수있는 방법이 없습니다.

개인적으로, 나는 이것이 실제로 좋은 것이라고 생각합니다. 우리는 다른 코드로부터 코드를 캡슐화하고 보호하는 데 익숙해 져서 때때로 발신자를 신뢰할 수있는 동료 나 고객보다는 악의적 인 잘못된 크레인으로 취급합니다. 나는 모든 사람이 경계를 존중하고 자신의 것을 돌보는 "당신의 일을하고 내 채굴을합니다"라는 사고 방식으로 코딩하는 것이 매우 유쾌하다는 것을 알게됩니다. Objective-C의 "태도"는 엄격한 집행이 아니라 공동체 신뢰 중 하나라고 말할 수 있습니다. 예를 들어, 나는 내 책상에 오는 사람을 돕게되어 기쁩니다. 그러나 누군가가 내 물건을 엉망으로 만들거나 묻지 않고 물건을 움직여도 정말 화가 났을 것입니다. 잘 설계된 코드는 편집증이나 사회 병리성 일 필요는 없으며 함께 잘 작동해야합니다. :-)

즉, 사용자에게 인터페이스를 노출시키는 데 원하는 과립성 수준에 따라 인터페이스를 구조화하기위한 많은 접근법이 있습니다. 공개 헤더에서 선언하는 모든 방법은 누구나 사용할 수있는 공정한 게임입니다. 숨겨지는 방법 선언은 자동차 나 집을 잠그는 것과 비슷합니다. 아마도 모든 사람을 막을 수는 없지만 (1) 엉망이되어서는 안되는 무언가로 유혹하지 않음으로써 "정직한 사람들을 정직하게 유지합니다". ) 누구든지 하다 들어가는 것은 확실히 그들이해야한다는 것을 알게 될 것이며, 실제로 부정적인 결과를 불평 할 수는 없습니다.

아래는 파일 이름 지정에 사용하는 일부 규칙이며 각 파일에서 발생하는 내용입니다. 하단의 .M 파일에서 시작하여 각 파일에는 위에 포함됩니다. (엄격한 포함 체인을 사용하면 중복 심볼 경고와 같은 것들을 방지 할 수 있습니다.) 이러한 레벨 중 일부는 Cocoa 프레임 워크와 같은 더 큰 재사용 가능한 구성 요소에만 적용됩니다. 당신의 필요에 따라 그들을 조정하고 당신에게 어울리는 이름을 사용하십시오.

• MyClass.h - 공개 API (응용 프로그램 프로그래밍 인터페이스)
• MyClass_Private.h -회사 내부 SPI (시스템 프로그래밍 인터페이스)
• MyClass_Internal.h -프로젝트 내부 IPI (내부 프로그래밍 인터페이스)
• MyClass.m - 구현, 일반적으로 모든 API/SPI/IPI 선언
• MyClass_Foo.m - 카테고리와 같은 추가 구현

API는 모든 사람이 사용하기위한 것이며 공개적으로 지원됩니다 (보통 Foo.framework/Headers). SPI는 코드의 내부 클라이언트에 대한 추가 기능을 노출 시키지만 지원이 제한되고 인터페이스가 변경 될 수 있다는 이해를 통해 (일반적으로 Foo.framework/PrivateHeaders). IPI는 프로젝트 자체 외부에서 절대 사용해서는 안되는 구현 별 세부 사항으로 구성 되며이 헤더는 프레임 워크에 전혀 포함되지 않습니다. SPI 및 IPI 통화를 사용하기로 선택한 사람은 누구나 자신의 위험에 처하게되며 일반적으로 변경 사항이 코드를 위반할 때 해를 끼치게됩니다. :-)

Answer 2

헤더 파일의 메소드를 선언하면 컴파일러 경고 만 중지됩니다. Objective-C는 동적 언어이므로 해당 메소드가 외부로 선언되었는지 여부에 관계없이 메소드 (메시지 보내기)를 객체로 호출 할 수 있습니다.

또한,이를 호출하는 코드 위의 .M 파일에서 메소드를 정의하면 (게으른 선언) 경고가 발생하지 않습니다. 그러나 같은 것이 적용되면, 메시지를 선언하지 않고 객체에 보낼 수 있습니다.

물론 - 이것은 목표 c에 개인 방법이 없음을 의미합니다. 클래스 구현을 호출 할 수있는 모든 방법.

개인 취향. 공개 방법 인 경우 (즉, 외부에서 사용되는 방법). .h에서 그것을 선언하고 .m에서 정의하십시오. 가시성을 제한하려면 적어도 개인 방법임을 나타냅니다. 카테고리/클래스 확장 .m 파일에서. 많은 예제 코드가 게으른 선언 방법을 사용하지만.

Answer 3

Objective -C는 함수를 "메시지"로 취급하므로 "메시지"를 모든 객체에 보낼 수 있습니다. 심지어 인터페이스에서 명시 적으로 명시하지 않는 객체조차도 수용 할 수 있습니다. 결과적으로 OBJ-C에는 개인 회원과 같은 것이 없습니다.

이것은 매우 강력 할 수 있지만 새로운 OBJ -C 프로그래머, 특히 C ++, Java 또는 C#에서 나오는 새로운 OBJ -C 프로그래머에게는 혼란의 원천입니다. 기본 경험 규칙은 다음과 같습니다.

• 소비자가 처리 할 메시지를 알 수 있도록 @interface의 모든 공개 방법을 정의해야합니다.
• 컴파일러 메시지를 피하고 @implementation에서 메소드를 주문하지 않도록 @interface에서 @private 메소드를 정의해야합니다.
• 클래스를위한 특정 방법 규칙을 구현할 때 프로토콜을 사용해야합니다.

이것의 대부분은 개인적인 취향이지만 성가신 컴파일러 경고를 피하고 코드를 구성하는 데 도움이됩니다. 이해하기 쉽습니다.