이제 속성에 대한 “점”표기법이 있습니다. 나는 여러 본 적이 뒤로 하고 forths 점 표기법 대 메시지 표기의 장점에 대한합니다. 응답을 더럽 히지 않기 위해 나는 질문에 어떤 방식 으로든 응답하지 않을 것입니다.
속성 액세스를위한 점 표기법과 메시지 표기법에 대해 어떻게 생각하십니까?
Objective-C에 초점을 맞추도록 노력하십시오. 제가 말하고자하는 한 가지 편견은 Objective-C가 Objective-C이므로 Java 또는 JavaScript와 같은 선호도는 유효하지 않다는 것입니다.
유효한 설명은 기술적 문제 (작업 순서, 캐스트 우선 순위, 성능 등), 명확성 (구조 대 객체 특성, 찬반 양론 모두!), 간결성 등과 관련이 있습니다.
저는 코드 규칙과 품질이 가장 중요한 대규모 프로젝트에서 작업 한 코드에서 엄격한 품질과 가독성을 갖춘 학교에 속해 있습니다 (한 번 쓰기는 천 번의 패러다임).
답변
동작에 점을 사용하지 마십시오. 일반적으로 속성으로 선언 된 속성과 같은 속성에 액세스하거나 설정하려면 점을 사용합니다.
x = foo.name; // good
foo.age = 42; // good
y = x.retain; // bad
k.release; // compiler should warn, but some don't. Oops.
v.lockFocusIfCanDraw; /// ooh... no. bad bad bad
Objective-C를 처음 접하는 사람들에게는 @property로 선언 된 것 외에는 점을 사용하지 않는 것이 좋습니다. 언어에 대한 느낌이 들면 옳다고 느끼는 일을하십시오.
예를 들어 다음은 완벽하게 자연 스럽습니다.
k = anArray.count;
for (NSView *v in myView.subviews) { ... };
clang 정적 분석기는 점이 특정 패턴에만 사용되는지 또는 특정 다른 패턴에는 사용되지 않는지 확인할 수있는 기능을 향상시킬 것입니다.
답변
먼저 Visual / Real Basic에서 프로그래밍을 시작한 다음 Java로 이동했기 때문에 점 구문에 상당히 익숙합니다. 그러나 마침내 Objective-C로 옮겨 대괄호에 익숙해 졌을 때 Objective-C 2.0의 도입과 도트 구문을보고 정말 마음에 들지 않는다는 것을 깨달았습니다. (다른 언어의 경우 괜찮습니다.
Objective-C에는 점 구문이있는 세 가지 주요 쇠고기가 있습니다.
쇠고기 # 1 : 오류가 발생하는 이유가 명확하지 않습니다. 예를 들어 다음과 같은 줄이있는 경우 :
something.frame.origin.x = 42;
그런 다음 something은 객체 이기 때문에 컴파일러 오류가 발생 하고 객체의 구조체를 표현식의 lvalue로 사용할 수 없습니다. 그러나 다음과 같은 경우 :
something.frame.origin.x = 42;
그런 다음 somethingNSRect 멤버가있는 구조체 자체 이므로 잘 컴파일 되며 lvalue로 사용할 수 있습니다.
이 코드를 채택했다면, 무엇인지 알아 내기 위해 시간을 할애해야 할 것 something입니다. 구조체입니까? 개체입니까? 그러나 대괄호 구문을 사용하면 훨씬 더 명확 해집니다.
[something setFrame:newFrame];
이 경우 something객체인지 아닌지 에 대한 모호성은 전혀 없습니다. 모호함의 도입은 내 쇠고기 # 1입니다.
Beef # 2 : C에서 점 구문은 메서드를 호출하는 것이 아니라 구조체의 멤버에 액세스하는 데 사용됩니다. 프로그래머는 개체 의 setFoo:및 foo메서드를 재정의 할 수 있지만 something.foo. 내 생각에 점 구문을 사용하는 표현식을 볼 때 나는 그것들이 ivar에 대한 간단한 할당이 될 것으로 기대하고 있습니다. 항상 그런 것은 아닙니다. 배열과 테이블 뷰를 중재하는 컨트롤러 객체를 고려하십시오. 을 호출 myController.contentArray = newArray;하면 이전 배열을 새 배열로 대체 할 것으로 예상됩니다. 그러나 원래 프로그래머 setContentArray:는 배열을 설정할뿐만 아니라 테이블 뷰를 다시로드하도록 재정의했을 수 있습니다 . 라인에서 그 행동의 징후는 없습니다. 내가 본다면[myController setContentArray:newArray];, 그러면 “아하, 방법입니다.이 방법이 무엇을하는지 알고 있는지 확인하기 위해이 방법의 정의를 확인해야합니다.”
따라서 Beef # 2에 대한 요약은 사용자 지정 코드로 점 구문의 의미를 재정의 할 수 있다는 것입니다.
쇠고기 # 3 : 안 좋은 것 같아요. Objective-C 프로그래머로서 저는 구문을 괄호로 묶는 데 전적으로 익숙합니다. 따라서 함께 읽고 아름다운 괄호의 줄과 줄을보고 갑자기 foo.name = newName; foo.size = newSize;등으로 깨지는 것은 나에게 약간 산만합니다. 어떤 것에는 점 구문 (C 구조체)이 필요하다는 것을 알고 있지만 그게 제가 사용하는 유일한 시간입니다.
물론 자신을 위해 코드를 작성하고 있다면 편한 것을 사용하십시오. 그러나 오픈 소싱을 계획중인 코드를 작성하거나 영원히 유지하지 않을 것으로 예상되는 코드를 작성하는 경우 대괄호 구문을 사용하는 것이 좋습니다. 물론 이것은 제 의견입니다.
점 구문에 대한 최근 블로그 게시물 : http://weblog.bignerdranch.com/?p=83
위 게시물에 대한 반박 : http://eschatologist.net/blog/?p=226 (점 구문을 선호하는 원본 기사 포함 : http://eschatologist.net/blog/?p=160 )
답변
저는 새로운 Cocoa / Objective-C 개발자입니다. 제 생각은 다음과 같습니다.
Obj-C 2.0으로 시작했지만 점 표기법이 더 친숙한 느낌 (자바가 제 모국어입니다) 임에도 불구하고 메시징 표기법을 고수합니다. 그 이유는 매우 간단합니다. 여전히 정확히 이해하지 못합니다. 언어에 점 표기법을 추가 한 이유. 나에게 그것은 불필요하고 “불순한”추가처럼 보인다. 누구든지 그것이 언어에 어떻게 도움이되는지 설명 할 수 있다면 나는 그것을 듣고 기뻐할 것입니다.
그러나 나는 이것을 스타일 선택이라고 생각 하고 다른 스타일 선택과 마찬가지로 일관되고 읽기 쉬운 한 옳고 그른 방법이 없다고 생각 합니다 (열리는 중괄호를 같은 줄에 두는 것과 같이 메소드 헤더 또는 다음 행).
답변
Objective-C 점 표기법은 일반적인 메시지 전달로 변환되는 구문 설탕이므로 내부적으로 아무것도 변경하지 않으며 런타임에 차이가 없습니다. 점 표기법은 메시지 전달보다 절대 빠르지 않습니다.
이 후 약간의 서문이 필요했습니다. 여기에 제가 본 장단점이 있습니다.
점 표기법의 장단점
-
찬성
- 가독성 : 점 표기법이 중첩 된 괄호 마사지보다 읽기 쉽습니다.
- 속성 및 속성과의 상호 작용을 단순화합니다. 속성에 점 표기법을 사용하고 메소드에 메시지 표기법을 사용 하여 신텍스 수준에서 상태와 동작을 분리 할 수 있습니다.
- 복합 할당 연산자 (1) 를 사용할 수 있습니다 .
@property컴파일러는 및 점 표기법을 사용하여 많은 작업을 수행하므로 속성을 가져오고 설정할 때 좋은 메모리 관리를위한 코드를 생성 할 수 있습니다. 이것이 바로 Apple 공식 가이드에서 점 표기법을 제안한 이유입니다.
-
단점
- 점 표기법은 선언 된 항목에만 액세스 할 수 있습니다.
@property - Objective-C는 표준 C (언어 확장) 위의 레이어이므로 액세스 된 엔티티가 객체인지 구조 체인지 점 표기법은 실제로 명확하지 않습니다. 종종 구조체의 속성에 액세스하는 것처럼 보입니다.
- 점 표기법으로 메서드를 호출하면 명명 된 매개 변수 가독성 이점 이 손실됩니다.
- 혼합 된 메시지 표기법과 점 표기법이 두 가지 다른 언어로 코딩하는 것처럼 보일 때
- 점 표기법은 선언 된 항목에만 액세스 할 수 있습니다.
코드 예 :
(1) 복합 연산자 사용 코드 예 :
//Use of compound operator on a property of an object
anObject.var += 1;
//This is not possible with standard message notation
[anObject setVar:[anObject var] + 1];
답변
언어 자체와 일치하는 언어 스타일을 사용하는 것이 여기에서 가장 좋은 조언입니다. 그러나 이것은 OO 시스템에서 기능 코드를 작성하는 경우가 아니며 (또는 그 반대로) 점 표기법은 Objective-C 2.0 구문의 일부입니다.
모든 시스템이 오용 될 수 있습니다. 모든 C 기반 언어에서 전처리 기가 존재하는 것은 정말 이상한 일을하기에 충분합니다. 그냥보고 난독 C 콘테스트 당신이 얻을 수있는 방법 이상한 정확히 확인해야합니다. 그것은 전처리 기가 자동으로 불량이고 절대 사용해서는 안된다는 것을 의미합니까?
인터페이스에서 이와 같이 정의 된 속성에 액세스하기 위해 점 구문을 사용하는 것은 남용 될 수 있습니다. potentia에서 학대의 존재가 반드시 그것에 반대하는 주장은 아닙니다.
속성 액세스에는 부작용이있을 수 있습니다. 이는 해당 속성을 획득하는 데 사용되는 구문과 직교합니다. CoreData, 위임, 동적 속성 (첫 번째 + 마지막 = 전체)은 모두 내부적으로 일부 작업을 수행합니다. 그러나 그것은 ‘인스턴스 변수’와 객체의 ‘속성’을 혼동합니다. 속성을 반드시있는 그대로 저장해야하는 이유가 없습니다. 특히 계산할 수있는 경우 (예 : 문자열 길이) 그렇습니다. 따라서 foo.fullName을 사용하든 [foo fullName]을 사용하든 여전히 동적 평가가있을 것입니다.
마지막으로 속성의 동작 ( lvalue 로 사용될 때 )은 복사본을 가져 왔는지 또는 유지하는지 여부와 같이 객체 자체에 의해 정의됩니다. 이렇게하면 메서드를 다시 구현할 필요없이 나중에 속성 정의 자체에서 동작을 쉽게 변경할 수 있습니다. 이는 접근 방식의 유연성을 추가하고 결과적으로 더 적은 (구현) 오류가 발생할 가능성이 있습니다. 여전히 잘못된 방법 (즉, 유지 대신 복사)을 선택할 가능성이 있지만 이는 구현보다는 아키텍처 문제입니다.
궁극적으로 ‘구조체처럼 보입니까?’라는 질문으로 귀결됩니다. 이것은 아마도 지금까지 논쟁의 주요 차별화 요소 일 것입니다. 구조체가 있으면 객체가있는 경우와 다르게 작동합니다. 그러나 그것은 항상 사실이었습니다. 구조체에 메시지를 보낼 수 없으며 스택 기반인지 참조 / malloc 기반인지 알아야합니다. 이미 사용 측면에서 다른 멘탈 모델이 있습니다 ([[CGRect alloc] init] 또는 struct CGRect?). 행동 측면에서 통합 된 적이 없습니다. 당신은 각각의 경우에 무엇을 다루고 있는지 알아야합니다. 객체에 대한 속성 표시를 추가하는 것은 데이터 유형이 무엇인지 아는 프로그래머를 혼동하지 않을 것입니다. 그렇지 않으면 더 큰 문제가 생깁니다.
일관성에 관해서는; (목표-) C는 그 자체로 일관성이 없습니다. = 소스 코드의 어휘 위치를 기반으로 할당 및 동등성에 모두 사용됩니다. *는 포인터와 곱셈에 사용됩니다. BOOL은 YES와 NO가 각각 1과 0 임에도 불구하고 바이트 (또는 다른 정수 값)가 아닌 문자입니다. 일관성이나 순 결함은 언어의 목적이 아닙니다. 일을 끝내는 것이 었습니다.
따라서 사용하고 싶지 않다면 사용하지 마십시오. 다른 방식으로 수행하십시오. 당신이 그것을 사용하고 싶고 그것을 이해한다면 그것을 사용하는 것이 좋습니다. 다른 언어는 일반 데이터 구조 (맵 / 구조체) 및 객체 유형 (속성 포함)의 개념을 다룹니다. 하나는 단순한 데이터 구조이고 다른 하나는 풍부한 객체라는 사실에도 불구하고 두 가지 모두에 동일한 구문을 사용하는 경우가 많습니다. Objective-C의 프로그래머는 선호하는 프로그래밍 스타일이 아니더라도 모든 스타일의 프로그래밍을 처리 할 수있는 동등한 능력이 있어야합니다.
답변
나는 속성에 사용하기 때문에
for ( Person *person in group.people){ ... }
보다 읽기 쉽습니다.
for ( Person *person in [group people]){ ... }
두 번째 경우에는 두뇌를 메시지 전송 모드로 전환하여 가독성을 방해하는 반면, 첫 번째 경우에는 그룹 객체의 사람 속성에 액세스하고 있음이 분명합니다.
예를 들어 컬렉션을 수정할 때도 사용합니다.
[group.people addObject:another_person];
보다 읽기 쉽습니다.
[[group people] addObject:another_person];
이 경우 강조점은 두 개의 메시지를 연결하는 대신 배열에 객체를 추가하는 작업에 있어야합니다.
답변
저는 주로 Objective-C 2.0 시대에 자랐으며 점 표기법을 선호합니다. 나에게 그것은 추가 괄호 대신에 점을 사용할 수있는 코드의 단순화를 허용합니다.
또한 점 구문 은 메시지를 보내는 대신 객체의 속성에 액세스하는 것처럼 느껴지 므로 점 구문을 좋아합니다 (물론 점 구문은 실제로 메시지 전송으로 변환되지만 외관상 , 점이 다르게 느껴집니다). 이전 구문으로 “게터를 호출”하는 대신 객체에서 유용한 것을 직접 얻는 것처럼 느껴집니다.
이에 대한 논쟁 중 일부는 “하지만 우리는 이미 도트 구문을 가지고 있으며 structs!”에 관한 것입니다. 그리고 그것은 사실입니다. 그러나 (다시 말하지만 이것은 심리적입니다) 그것은 기본적으로 나에게 똑같은 느낌입니다. 점 구문을 사용하여 객체의 속성에 액세스하는 것은 구조의 멤버에 액세스하는 것과 동일하게 느껴집니다 .
**** 편집 : bbum이 지적했듯이 객체에 대한 모든 메서드를 호출하는 데 점 구문을 사용할 수도 있습니다 (나는 이것을 알지 못했습니다). 그래서 점 구문에 대한 제 의견은 일상적인 메시지 전송이 아닌 객체의 속성을 처리하기위한 것이라고 말할 것입니다 **
