이제 속성에 대한 "점"표기법이 있습니다. 나는 여러 본 적이 뒤로 하고 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 정적 분석기는 점이 특정 패턴에만 사용되는지 또는 특정 다른 패턴에는 사용되지 않는지 확인할 수있는 기능을 향상시킬 것입니다.
.uppercaseString, 클래스가 의도를 표현할 수 있는지 여부와 같은 메서드를 사용할지 여부가 모호하지 않을 것입니다. 컴파일러에 의해 시행됩니다. 아마도 점 표기법의 현재 구현이 필요한 누락 된 것이있을 수 있습니다.
@property만 제한 될 수 있었지만 API 소비자가 정보의 또 다른 부울 차원을 배우고 API 디자이너가 @property. Xcode는 @property코드를 완료 할 때 묵시적인 방법을 선호합니다 .
@property언어를 처음 사용할 때만 선언 된 접근 자 와 함께 점을 사용하는 것이 좋습니다 . Objective-C에서 코딩에 대한 자신감을 얻으면 올바른 일을하십시오. 흥미 롭다. 우리 중 많은 사람들이 점을 매우 제한적으로 사용했습니다.
먼저 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 )
something 객체이지만 원래 작성자가 구조체 (속도, 메모리 사용량 감소 등)를 만든 몇 군데를 보았습니다. 코드가 제대로 작동하지 않는 이유를 알아 내려면 몇 분 정도 시간을 투자해야합니다. t 컴파일.
저는 새로운 Cocoa / Objective-C 개발자입니다. 제 생각은 다음과 같습니다.
Obj-C 2.0으로 시작했지만 점 표기법이 더 친숙한 느낌 (자바가 제 모국어입니다) 임에도 불구하고 메시징 표기법을 고수합니다. 그 이유는 매우 간단합니다. 여전히 정확히 이해하지 못합니다. 언어에 점 표기법을 추가 한 이유. 나에게 그것은 불필요하고 "불순한"추가처럼 보인다. 누구든지 그것이 언어에 어떻게 도움이되는지 설명 할 수 있다면 나는 그것을 듣고 기뻐할 것입니다.
그러나 나는 이것을 스타일 선택이라고 생각 하고 다른 스타일 선택과 마찬가지로 일관되고 읽기 쉬운 한 옳고 그른 방법이 없다고 생각 합니다 (열리는 중괄호를 같은 줄에 두는 것과 같이 메소드 헤더 또는 다음 행).
Objective-C 점 표기법은 일반적인 메시지 전달로 변환되는 구문 설탕이므로 내부적으로 아무것도 변경하지 않으며 런타임에 차이가 없습니다. 점 표기법은 메시지 전달보다 절대 빠르지 않습니다.
이 후 약간의 서문이 필요했습니다. 여기에 제가 본 장단점이 있습니다.
찬성
@property컴파일러는 및 점 표기법을 사용하여 많은 작업을 수행하므로 속성을 가져오고 설정할 때 좋은 메모리 관리를위한 코드를 생성 할 수 있습니다. 이것이 바로 Apple 공식 가이드에서 점 표기법을 제안한 이유입니다.단점
@property(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이 지적했듯이 객체에 대한 모든 메서드를 호출하는 데 점 구문을 사용할 수도 있습니다 (나는 이것을 알지 못했습니다). 그래서 점 구문에 대한 제 의견은 일상적인 메시지 전송이 아닌 객체의 속성을 처리하기위한 것이라고 말할 것입니다 **
나는 메시징 구문을 훨씬 더 선호하지만 그게 내가 배운 것이기 때문이다. 내 수업이 많고 Objective-C 1.0 스타일이 아닌 것을 고려할 때 나는 그것들을 혼합하고 싶지 않을 것입니다. 나는 도트 구문을 사용하지 않는 "내가 익숙한 것"외에는 진짜 이유가 없습니다.
[myInstance.methodThatReturnsAnObject sendAMessageToIt]
이유는 모르겠지만 그럴만한 이유없이 정말 화나게합니다. 나는 단지 그렇게 생각한다
[[myInstance methodThatReturnsAnObject] sendAMessageToIt]
더 읽기 쉽습니다. 그러나 각자 자신에게!
[self.title lowercaseString]또는 무언가. 그러나 구문을 혼합하고 일치시키는 것이 왜 성가 신지 스타일 적으로 알 수 있습니다. 내가하는 유일한 이유는 속성이 무엇인지, 객체를 반환하는 메소드가 무엇인지 똑바로 유지하는 것입니다.
솔직히 스타일 문제라고 생각합니다. 저는 개인적으로 도트 구문에 반대합니다 (특히 변수 읽기 / 쓰기뿐만 아니라 메서드 호출에 사용할 수 있다는 것을 알게 된 후). 그러나 사용하려는 경우 변수에 액세스하고 변경하는 것 외에는 사용 하지 않는 것이 좋습니다 .
객체 지향 프로그래밍의 주요 장점 중 하나는 객체의 내부 상태에 직접 액세스 할 수 없다는 것입니다.
점 구문은 마치 상태가 직접 액세스되는 것처럼 보이고 느끼게하는 시도 인 것 같습니다. 그러나 실제로는 -foo 및 -setFoo : 동작에 대한 구문 설탕 일뿐입니다. 나 자신은 스페이드를 스페이드라고 부르는 것을 선호합니다. 점 구문은 코드가 더 간결 할 정도로 가독성을 높이지만 실제로 -foo 및 -setFoo :를 호출하고 있다는 사실을 기억하지 못하면 문제를 일으킬 수 있으므로 이해에 도움이되지 않습니다.
합성 된 접근자는 상태에 직접 접근하는 객체를 쉽게 작성하려는 시도 인 것 같습니다. 제 생각에는 이것이 객체 지향 프로그래밍이 피하도록 만들어진 프로그램 디자인의 종류를 정확히 장려한다는 것입니다.
균형 적으로 저는 점 구문과 속성이 도입되지 않았 으면합니다. 저는 사람들에게 ObjC가 Smalltalk와 더 비슷하게 만들기 위해 C에 대한 몇 가지 깨끗한 확장이라고 말할 수 있었으며 더 이상 사실이라고 생각하지 않습니다.
많은 사람들이 '속성'과 '인스턴스 변수'를 혼동하고있는 것 같습니다. 속성의 요점은 내부를 몰라도 객체를 수정할 수 있도록하는 것입니다. 인스턴스 변수는 대부분 속성의 '구현'이지만 (이는 '인터페이스') 항상 그런 것은 아닙니다. 속성이 ivar에 해당하지 않고 대신 반환 값 '을 계산합니다. 즉석에서'.
그렇기 때문에 "점 구문이 변수에 액세스하고 있다고 생각하도록 속여서 혼란 스럽습니다"라는 생각이 잘못되었다고 생각합니다. 점 또는 대괄호, 내부에 대해 가정해서는 안됩니다. ivar가 아니라 속성입니다.
->그 역할을 수행하는 것은 화살표 연산자 입니다 (물론 ivar가 액세스가 제한되지 않는다고 말할 때마다).
점 표기법은 메시지가 아닌 구조체의 멤버에 대한 액세스처럼 보이도록합니다. 어떤 경우에는 잘 작동 할 수 있습니다. 그러나 곧 누군가는 다음과 같은 것을 생각 해낼 것입니다.
NSView *myView = ...;
myView.frame.size.width = newWidth;
괜찮아 보인다. 그러나 그렇지 않습니다. 그것은
[myView frame].size.width = newWidth;
작동하지 않습니다. 컴파일러는 첫 번째를 허용하지만 두 번째는 허용하지 않습니다. 그리고 처음에 오류 또는 경고를 내 보냈다고해도 이것은 혼란 스러울뿐입니다.
게으름이라고 부르지 만 '.'하나만 입력해야한다면 대 2 [] 매번 동일한 결과를 얻으려면 나는 하나를 선호합니다. 나는 장황한 언어를 싫어합니다. lisp의 ()는 나를 미치게 만들었습니다. 수학과 같은 우아한 언어는 간결하고 효과적이며 다른 모든 언어는 부족합니다.
개인적으로 코드에서 점 표기법을 전혀 사용하지 않습니다. 필요한 경우 CoreData KVC 바인딩 식에서 만 사용합니다.
나를 위해 코드에서 사용하지 않는 이유는 점 표기법이 setter 의미를 숨기기 때문입니다. 점 표기법으로 속성을 설정하는 것은 setter 의미 (할당 / 유지 / 복사)에 관계없이 항상 할당처럼 보입니다. 메시지 표기법을 사용하면 수신 객체가 setter에서 발생하는 일을 제어 할 수 있으며 이러한 효과를 고려해야한다는 사실을 강조합니다.
나는 KVC 호환 또는 선언 된 속성의 값을 검색 할 때 점 표기법을 사용할지 여부를 여전히 고려하고 있습니다. 지금은 일관성을 위해 메시지 표기법을 고수하고 있습니다.
좋습니다. Objective-C의 점 표기법은 실제로 이상하게 보입니다. 그러나 나는 그것 없이는 여전히 다음을 할 수 없습니다.
int width = self.frame.size.width;
잘 작동하지만 :
int height = [[[self frame] size] height];
"포인터 유형으로 변환 할 수 없음"을 제공합니다. 그래도 내 코드가 메시지 표기법과 일치하도록 유지하고 싶습니다.
이것은 훌륭한 질문이며 이에 대한 여러 가지 답변을 봅니다. 많은 사람들이 주제를 다루었지만 다른 각도에서 대답하려고 노력할 것입니다 (일부는 암시 적으로 수행했을 수도 있음).
'점'표기법을 사용하면 메서드에 대한 대상의 해결이 컴파일 타임에 수행됩니다. 메시지 전달을 사용하면 대상의 확인이 런타임 실행으로 지연됩니다. 대상이 컴파일 타임에 확인되면 런타임에 대상을 확인하는 데 약간의 오버 헤드가 포함되므로 실행이 더 빠릅니다. (시차가 많이 중요하지는 않습니다). 이미 객체의 인터페이스에 속성을 정의 했으므로 속성에 대한 대상의 해상도를 런타임에 다르게 지정할 필요가 없으므로 점 표기법은 속성에 액세스하는 데 사용해야하는 표기법입니다.