Запись через точку по сравнению с нотацией сообщения для заявленных свойств

На мой взгляд, точечный синтаксис делает Objective-C менее похожим на Smalltalk. Код может выглядеть проще, но добавляет двусмысленности. Это структура , объединение или объект?

Honestly, I think it comes down to a matter of style. I personally am against the dot syntax (especially after just finding out that you can use it for method calls and not just reading/writing variables). However, if you are going to use it, I would strong recommend not using it for anything other than accessing and changing variables.

Я предпочитаю синтаксис обмена сообщениями ... но только потому, что я научился именно этому. Учитывая, что многие из моих классов и те, что не относятся к стилю Objective-C 1.0, я бы не хотел их смешивать. У меня нет реальной причины, кроме «того, к чему я привык», чтобы не использовать синтаксис с точкой ... ИСКЛЮЧАЯ это, это сводит меня с ума

[myInstance.methodThatReturnsAnObject sendAMessageToIt]

Я не знаю почему, но меня это действительно бесит, без уважительной причины. Я просто думаю, что выполнение

[[myInstance methodThatReturnsAnObject] sendAMessageToIt]

более читабельно. Но каждому свое!

Я использую его для свойств, потому что

for ( Person *person in group.people){ ... }

немного легче читать, чем

for ( Person *person in [group  people]){ ... }

, во втором случае читаемость прерывается помещением вашего мозг в режим отправки сообщений, тогда как в первом случае ясно, что вы обращаетесь к свойству people объекта группы.

Я также буду использовать его при изменении коллекции, например:

[group.people addObject:another_person];

немного читабельнее, чем

[[group people] addObject:another_person];

Акцент в этом случае должен быть сделан на добавлении объекта в массив вместо объединения двух сообщений.

I ' В основном он вырос в эпоху Objective-C 2.0, и я предпочитаю точечную нотацию. Для меня это позволяет упростить код, вместо дополнительных скобок я могу просто использовать точку.

Мне также нравится синтаксис точки, потому что он заставляет меня чувствовать , как будто я получаю доступ к свойство объекта, а не просто посылать ему сообщение (конечно, точечный синтаксис действительно переводится в отправку сообщения, но для внешнего вида точка выглядит иначе). Вместо того, чтобы «вызывать геттер» с помощью старого синтаксиса, мне кажется, что я напрямую получаю что-то полезное от объекта.

Некоторые дискуссии по этому поводу связаны с тем, «Но у нас уже есть точечный синтаксис, и он для структур ! ". И это правда. Но (и опять же, это чисто психологически) я чувствую то же самое. Доступ к свойству объекта с использованием точечного синтаксиса ощущается так же, как доступ к члену структуры, что является более или менее предполагаемым эффектом (на мой взгляд).

**** Изменить: Как указал bbum, вы также можете использовать точечный синтаксис для вызова любого метода объекта (я не знал об этом). Поэтому я скажу, что мое мнение о синтаксисе точек предназначено только для работы со свойствами объекта, а не для повседневной отправки сообщений **

Я новый разработчик Cocoa / Objective-C, и мое мнение таково:

Я придерживаюсь нотации обмена сообщениями, хотя я начал с Obj-C 2.0, и хотя точечная нотация кажется мне более привычной (Java - мой первый язык). Моя причина для этого довольно проста: я до сих пор не понимаю, почему они добавили точечную нотацию в язык. Мне это кажется ненужным, «нечистым» дополнением. Хотя, если бы кто-нибудь мог объяснить, какую пользу это приносит языку, я был бы рад это услышать.

Однако я считаю это стилистическим выбором и не думаю, что есть правильный или неправильный путь, как до тех пор, пока он непротиворечив и удобочитаем , как и в случае любого другого стилистического выбора (например, размещение открывающей фигурной скобки в той же строке, что и заголовок метода, или в следующей строке).

Лучшим советом здесь является использование стиля языка, соответствующего самому языку. Однако это не относится к написанию функционального кода в объектно-ориентированной системе (или наоборот), и точечная нотация является частью синтаксиса в Objective-C 2.0.

Любая система может быть использована неправильно. Существования препроцессора во всех языках, основанных на C, достаточно, чтобы делать действительно довольно странные вещи; просто посмотрите Obfuscated C Contest , если вам нужно точно увидеть, насколько это странно. Означает ли это, что препроцессор автоматически становится плохим и вам никогда не следует его использовать?

Использование точечного синтаксиса для доступа к свойствам, которые были определены как таковые в интерфейсе, открыто для злоупотреблений. Существование потенциального злоупотребления не обязательно должно быть аргументом против.

Доступ к собственности может иметь побочные эффекты. Это ортогонально синтаксису, используемому для получения этого свойства. CoreData, делегирование, динамические свойства (first + last = full) обязательно сделают некоторую работу под прикрытием. Но это привело бы к путанице «переменные экземпляра» со «свойствами» объекта. Нет причин, по которым свойства должны обязательно храниться как есть, особенно если они могут быть вычислены (например, длина строки). Поэтому независимо от того, используете ли вы foo.fullName или [foo fullName], все равно будет выполняться динамическая оценка.

Наконец, поведение свойства (при использовании в качестве lvalue ) определяется самим объектом, например, будет ли сделана копия или сохранена. Это упрощает изменение поведения позже - в самом определении свойства - вместо повторной реализации методов. Это увеличивает гибкость подхода, в результате чего вероятность возникновения меньшего количества ошибок (реализации). По-прежнему существует возможность выбрать неправильный метод (т.е. скопировать вместо сохранения), но это проблема архитектуры, а не реализации.

В конечном счете, все сводится к вопросу «выглядит ли это как структура». Это, вероятно, основная разница в дебатах до сих пор; если у вас есть структура, она работает иначе, чем если бы у вас есть объект. Но это всегда было правдой; вы не можете отправить структуру сообщения, и вам нужно знать, на основе стека или ссылки / malloc. Уже существуют ментальные модели, которые различаются по использованию ([[CGRect alloc] init] или struct CGRect?). Они никогда не были едины в поведении; тебе нужно знать, что ты в каждом конкретном случае. Добавление обозначения свойств для объектов вряд ли запутает любого программиста, который знает, каковы их типы данных; а если они этого не сделают, у них будут большие проблемы.

Что касается последовательности; (Цель-) C противоречиво внутри себя. = используется как для присваивания, так и для равенства в зависимости от лексической позиции в исходном коде. * используется для указателей и умножения. BOOL - это символы, а не байты (или другое целочисленное значение), несмотря на то, что YES и NO равны 1 и 0 соответственно. Последовательность или чистота - это не то, для чего был разработан язык; это было сделано для того, чтобы что-то сделать.

Так что, если вы не хотите использовать это, не используйте его. Сделайте это по-другому. Если вы хотите его использовать и понимаете, это нормально, если вы им воспользуетесь. Другие языки имеют дело с концепциями общих структур данных (карты / структуры) и типов объектов (со свойствами), часто используя один и тот же синтаксис для обоих, несмотря на то, что один является просто структурой данных, а другой - многофункциональным объектом. Программисты на 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;

Тогда это компилируется нормально, потому что something является самой структурой, которая имеет член NSRect, а я может использовать его как lvalue.

Если бы я использовал этот код, мне пришлось бы потратить некоторое время, пытаясь выяснить, что такое что-то . Это структура? Это объект? Однако, когда мы используем синтаксис скобок, он становится намного яснее:

и я могу использовать его как lvalue.

Если бы я использовал этот код, мне пришлось бы потратить некоторое время, пытаясь выяснить, что такое что-то . Это структура? Это объект? Однако, когда мы используем синтаксис скобок, он становится намного яснее:

и я могу использовать его как lvalue.

Если бы я использовал этот код, мне пришлось бы потратить некоторое время, пытаясь выяснить, что такое что-то . Это структура? Это объект? Однако, когда мы используем синтаксис скобок, он становится намного яснее:

[something setFrame: newFrame];

В этом случае нет никакой двусмысленности, является ли something объектом или нет. Введение двусмысленности - моя претензия № 1.

Говядина № 2: В C синтаксис с точкой используется для доступа к элементам структур, а не для вызова методов. Программисты могут переопределить методы setFoo: и foo объектов, но по-прежнему обращаться к ним через something.foo . На мой взгляд, когда я вижу выражения, использующие точечный синтаксис, я ожидаю, что они будут простым назначением в ivar. Это не всегда так. Рассмотрим объект контроллера, который является посредником между массивом и табличным представлением. Если я вызову myController.contentArray = newArray; , я ожидаю, что он заменит старый массив новым массивом. Однако, исходный программист мог переопределить setContentArray: , чтобы не только установить массив, но и перезагрузить табличное представление. Судя по строке, нет никаких указаний на такое поведение. Если бы я увидел [myController setContentArray: newArray]; , то я бы подумал: «Ага, метод. Мне нужно посмотреть определение этого метода, чтобы убедиться, что я знаю, что он делает».

Итак, я думаю, что мое краткое изложение Beef # 2 состоит в том, что вы можете переопределить значение синтаксиса точки с помощью специального кода.

Beef # 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 )

затем используйте то, что вам удобно. Но если вы пишете код, который планируете использовать с открытым исходным кодом, или пишете то, что не ожидаете поддерживать вечно, то я настоятельно рекомендую использовать синтаксис скобок. Это, конечно, только мое мнение.

Недавнее сообщение в блоге против синтаксиса точки: http://weblog.bignerdranch.com/?p=83

Опровержение вышеуказанного сообщения: http: //eschatologist.net/blog/?p=226 (с оригинальной статьей в пользу точечного синтаксиса: http://eschatologist.net/blog/?p=160 )

затем используйте то, что вам удобно. Но если вы пишете код, который планируете использовать с открытым исходным кодом, или пишете то, что не ожидаете поддерживать вечно, то я настоятельно рекомендую использовать синтаксис скобок. Это, конечно, только мое мнение.

Недавнее сообщение в блоге против синтаксиса точки: http://weblog.bignerdranch.com/?p=83

Опровержение вышеуказанного сообщения: http: //eschatologist.net/blog/?p=226 (с оригинальной статьей в пользу точечного синтаксиса: http://eschatologist.net/blog/?p=160 )

Думаю, я мог бы переключиться на обмен сообщениями вместо точечной нотации, потому что в моей голове object.instanceVar - это просто instanceVar , принадлежащий объекту , для меня это совсем не похоже на вызов метода , что и есть, поэтому в вашем методе доступа могут происходить какие-то вещи, независимо от того, используете ли вы instanceVar или self.instanceVar может иметь гораздо большую разницу, чем просто неявное и явное. Только мои 2 цента.

Одним из основных преимуществ объектно-ориентированного программирования является отсутствие прямого доступа к внутреннему состоянию объектов.

Точечный синтаксис кажется мне попыткой придать ему вид и ощущение, что к состоянию обращаются напрямую. Но на самом деле это просто синтаксический сахар над поведением -foo и -setFoo :. Лично я предпочитаю называть вещи своими именами. Точечный синтаксис способствует удобочитаемости в той степени, в которой код более лаконичен, но он не помогает пониманию, потому что если не учитывать, что вы действительно вызываете -foo и -setFoo:, это может означать проблемы.

Мне кажутся синтезированные аксессоры чтобы быть попыткой упростить запись объектов с прямым доступом к состоянию. Я считаю, что это способствует созданию именно такого типа программ, для предотвращения которого создавалось объектно-ориентированное программирование.

В целом, я бы предпочел точечный синтаксис и свойства никогда не вводились. Раньше я мог говорить людям, что ObjC - это несколько чистых расширений для C, чтобы сделать его более похожим на Smalltalk, и я больше не думаю, что это правда.

Лично я вообще не использую точечную нотацию в коде. Я использую его только в выражении привязки CoreData KVC, когда это необходимо.

Причина, по которой я не использую их в коде для меня, заключается в том, что точечная нотация скрывает семантику установщика. Установка свойства в точечной нотации всегда выглядит как присваивание независимо от семантики установщика (присваивать / сохранять / копировать). Использование нотации сообщения делает видимым, что принимающий объект имеет контроль над тем, что происходит в установщике, и подчеркивает тот факт, что эти эффекты необходимо учитывать.

Я все еще обдумываю, могу ли я использовать точечную нотацию при извлечении значения KVC-совместимого или объявленного свойства, потому что оно, по общему признанию, немного более компактно и читаемо, и в нем нет скрытой семантики. Прямо сейчас я придерживаюсь нотации сообщений для единообразия.

Точка-нотация пытается сделать сообщения похожими на доступ к элементу структуры, которым они не являются. В некоторых случаях может работать нормально. Но скоро кто-нибудь придумает что-то вроде этого:

NSView *myView = ...;
myView.frame.size.width = newWidth;

Выглядит неплохо. Но это не так. Это то же самое, что

[myView frame].size.width = newWidth;

который не работает. Компилятор принимает первое, но правомерно не второе. И даже если он выдал ошибку или предупреждение для первого, это просто сбивает с толку.