Соглашение об именовании класса Objective C против Дяди Боба - PullRequest
7 голосов
/ 06 марта 2012

В Chapter 2: Meaningful Names Дядя Боб пишет:

Не добавлять бесплатный контекст

В воображаемом приложении под названием «Заправка Делюкс» плохая идея ставить перед каждым классом префикс GDS. Честно говоря, вы работаете против своих инструментов. Вы набираете G и клавишу завершения печати и получаете список длиной в милю каждого класса в вашей системе

На самом деле это то, что я обнаружил в первые дни с Objective-C чуть больше года назад. После Java это было довольно неутешительно, но я думал, что я только один, кто раздражен об этом :) Я понимаю, что книга «Чистый код» в большинстве случаев относится к Java, а Java имеет пространства имен (пакеты) в отличие от Objective-C.

Используете ли вы 2-3-буквенный префикс в ваших классах, если вы создаете приложение, а не библиотеку? Как вы думаете, это плохой языковой дизайн, языковая «фича» или Дядя Боб был здесь не прав?

Ответы [ 6 ]

13 голосов
/ 06 марта 2012

Возможно, ключевое слово здесь - безвозмездно .В Objective-C префиксы служат важной цели снижения вероятности конфликтов имен.В других языках, таких как Java и C ++, наличие поддержки пространств имен делает использование префиксов необоснованным (и нарушает часто цитируемый принцип DRY).Однако в Objective-C префиксы значимы, полезны и не безвозмездны.

3 голосов
/ 06 марта 2012

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

Многие языки имеют функцию, называемую пространства имен , где «полностью определенное» имя класса начинается с префикса иерархической серии имен.Например, класс String в Java - это, собственно, java.lang.String, а пользовательский класс - правильно com.whatever.foobar.MyClass.

К сожалению, пространства имен никогда не добавлялись в Objective-C, что означает, что ObjectiveСимволы -C (имена классов, имена протоколов и несколько других типов) не могут быть помещены в пространство имен даже при использовании Objective-C ++ (который имеет функцию пространства имен для функций, констант, структур и т. Д.)

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

Этот парень из дяди Боба негодяй говорит вам не делать этого, потому что пока выВ конечном итоге вы получите программу, которая не компилируется, и вы потеряете все преимущества пространств имен, которые до сих пор предлагают префиксы.Использует ли ваше приложение плагины?Вы должны префикс.Есть ли у вашего приложения публичный API?Вам нужно поставить префикс.

Теоретически, код в пределах одного приложения, которое никогда не касается внешнего мира, может обходиться без префиксов, но винт - продолжайте кодировать аккуратно и добавляйте префикс даже там.Это спасет вас от горя позже.

0 голосов
/ 06 марта 2012

Помимо предотвращения коллизий, одно из преимуществ префиксов имен заключается в том, что вы сразу же знаете, с каким типом вы на самом деле имеете дело. Предположим, у вас был следующий код:

Color c = ...;
MultiValueMap m = ...;

С беглого взгляда на код и в зависимости от того, какие библиотеки вы использовали, эти типы могут быть из разных источников. Возможно, вам придется посмотреть, какой оператор include / import был создан, чтобы понять, что может делать тип (например, вы хотите изменить его, но в нем отсутствует метод, который, как вы уверены, существует).

В мире iOS вы сразу узнаете, является ли это UIColor против CGColor, и сразу получите контекст.

В прошлом на WWDC Apple проводила сеанс, на котором разъяснялись правила кодирования Какао / Objective-C. Я полагаю, что они упоминают этот аспект префиксов имен, поэтому вы можете захотеть найти одну из доступных записей. Другие разработчики C (например, разработчики ядра Linux) также по-разному не думают о пространствах имен C ++ (среди других функций C ++) по разным причинам.

0 голосов
/ 06 марта 2012

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

Иногда это раздражает меня в target-c, однако имеет некоторую легитимность, если у вас нет пакетов на вашем языке, поскольку вы можете «создавать» искусственные группы классов, такие как «NS», «UI», «MK 'и так далее в objc и какао.

0 голосов
/ 06 марта 2012

Хорошо, если у вас нет пространств имен, могут возникнуть конфликты имен.Вы можете видеть, что во многих библиотеках C они используют какой-то префикс.Поэтому я думаю, что есть веские причины иметь эти префиксы и другие причины не использовать его.Но что должно быть большой проблемой, чтобы изменить завершение, чтобы либо просто игнорировать префикс ввода трех букв вместо одной.

Итак, в конце концов, мне кажется, это дело вкуса.Я думаю, что было бы более важно иметь хорошие структуры классов с префиксами вместо беспорядка классов без префикса ....

Это не имеет ничего общего с плохим языковым дизайном ИМХО.Было время, когда программное обеспечение было не везде, и зачем тратить дополнительные усилия на пространства имен?И все же, как мы видим, даже в наши дни используются языки без пространств имен .....

0 голосов
/ 06 марта 2012

Лично я почти никогда не использую префиксы.Единственными исключениями являются классы, которые каким-то образом связаны друг с другом или все они должны присутствовать.

Пример:

Некоторое клиентское приложение для чата.Давайте назовем этот чат ExampleChat.

Тогда я бы использовал ECMessage, ECUser, ECRoom и т. Д., Чтобы легко увидеть, какие классы должны быть.

Или, если я сделаю несколько пользовательских ячеек для UITableView Я бы использовал префиксы, чтобы держать их все близко друг к другу и не пытался искать их в «списке длиной в милю».Пример:

ECTextMessageCell, ECSoundMessageCell, ECUploadMessageCell, ECJoinOrLeaveMessageCell и т. Д.

Это мое личное мнение, которое не может быть лучшим.Но это все еще проще для меня.

Надеюсь, это поможет

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...