Каковы ваши соглашения об именах для "частных" методов Objective-C? - PullRequest
20 голосов
/ 29 апреля 2011

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

Если оставить в стороне обоснование, я написал множество классов с загрузками 2 изчастные методы, но я действительно никогда не придумать шаблон для именования, что я действительно люблю (как я спорный ivar_ конвенции для Ивар).Известные примеры:

@interface myClass()

// I like this, but as we all know, Apple has dibs on this one, 
// and method name collisions are nasty.
- (void)_myPrivateMessage;

// The suffix version promoted by Google for ivars doesn't really translate
// well to method names in Objective-C, because of the way the method
// signature can be broken into several parts.
- (void)doWork_; // That's okay...
- (void)doWork_:(id)work with_:(id)something; // That's just ugly and tedious...
- (void)doWork_:(id)work with_:(id)something and_:(id)another; // My eyes...

// This version is suggested by Apple, and has the benefit of being officially 
// recommended. Alas, I don't like it: The capital letter is ugly. I don't like 
// underscores in the middle of the name. Worst of all, I have to type three characters 
// before code-sense does anything more useful than inform me that I am typing.
- (void)BF_doWork;

@end

На данный момент, есть kajillion различные способы, с помощью которых я могу манипулировать именами своих личных методов, но вместо того, чтобы что-то придумать, я решил сначала провести опрос для любого популярногоусловности, о которых я могу не знать.Итак, что вы использовали?

Ответы [ 7 ]

9 голосов
/ 29 апреля 2011

Я не различаю частные методы по имени. Вместо этого я держу их вне открытого интерфейса, объявляя их в части расширения класса файла .m, таким образом:

@interface MyClass ()
- (void)doWork;
@end
7 голосов
/ 17 июля 2011

Я использую двойное подчеркивание для своих личных методов:

- (void)__doSomethingPrivate;

Это почти похоже на один синтаксис подчеркивания (хорошо читаемый) и в то же время подтверждает руководство Apple.

4 голосов
/ 29 апреля 2011

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

3 голосов
/ 29 апреля 2011

Я использую два уровня приватных методов: слегка приватный и очень приватный.Немного закрытые методы - это методы, которые могут стать общедоступными, но в настоящее время нет.Обычно это удобные методы, которые я использую внутри себя, и я обычно не ставлю такую ​​большую защиту, если не решу обнародовать ее.Для очень приватных методов я игнорирую apple и использую префикс подчеркивания.Поскольку 99% моего кода находится в классах, которые я создаю, и у меня обычно есть префиксы в именах классов, шансы столкнуться с проблемами именования невелики.При добавлении кода в классы, которые я не создавал, я редко использую закрытые методы, но добавляю короткий префикс в тех редких случаях, когда я это делаю.

1 голос
/ 17 июля 2015

Использование фиксированного префикса поможет «скрыть» метод от внешнего мира, но не предотвратит случайное переопределение метода. Например. Однажды я расширил класс и создал метод:

- (void)private_close
{
    // ...
}

В результате поведение класса изменилось ужасным образом. Но почему? Оказалось, у суперкласса также было имя метода private_close и . Я случайно переопределил его, не вызывая super ! Как я должен знать? Нет предупреждения компилятора!

Неважно, является ли ваш префикс _ или __, или p, или private_, если он всегда один и тот же, у вас будут проблемы, подобные этой.

Таким образом, я префикс частных методов (и свойств!) С префиксом, который напоминает имя класса. Поэтому я беру заглавные буквы имени класса, чтобы сформировать «частный префикс»:

  • ComplexFileParser -> CFP
  • URLDownloadTask -> URLDT
  • SessionController -> SC

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

Также, когда вы создаете фреймворки, вы должны ставить перед всеми классами и другими символами префикс фреймворка (как Apple делает с NS..., CF..., CA..., SC..., UI... и т. Д.) И таким образом, этот префикс класса является частью частного префикса, а также делает коллизии еще менее вероятными:

  • Framework DecodingUtils.framework -> DU
    • Класс ComplexFileDecoder в каркасе -> DUComplexFileDecoder
      • Частный префикс -> DUCFD
        • Закрытый метод close -> - (void)DUCFD_close

В качестве альтернативы добавьте префикс в конце имени аргумента первого метода, чтобы улучшить автозаполнение:

- (void)doSomethingWith:(Type1)var1 parameters:(Type2)var2

станет

- (void)doSomethingWith_DUCFD:(Type1)var1 parameters:(Type2)var2

или всегда добавлять его только к последнему имени параметра:

- (void)doSomethingWith:(Type1)var1 parameters_DUCFD:(Type2)var2

или (теперь это становится действительно сумасшедшим) - добавьте фиктивный фиктивный параметр только для именования:

- (void)doSomethingWith:(Type1)var1 parameters:(Type2)var2 DUCFD:(id)x

, где x фактически никогда не используется в методе, и вы передаете nil для него:

[self doSomethingWith:var1 parameters:var2 DUCFD:nil];

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

#define priv DUCFD:nil
#define PRIVATE DUCFD:nil

// ...

[self doSomethingWith:var1 parameters:var2 priv];
[self doSomethingWith:var1 parameters:var2 PRIVATE];

Префикс и суффикс работают также со свойствами (и, следовательно, с их методами ivar, getter / setter), трюк препроцессора выше, конечно, не будет.

1 голос
/ 29 апреля 2011

Я префикс частных методов с 'p':

  • (void) pDoWork;
  • (void) pDoWork: (id) работает с: (id) чем-то;

Аналогично, я использую 's' для статических (или классовых) методов:

  • (* Вселенная) SGET; // используется для возврата одноэлементного объекта Universe.

Помимо соглашений об именах, я объявляю закрытые методы в файлах .m вместо файлов .h.

0 голосов
/ 27 ноября 2015

Относительно рекомендаций Apple. Возможно, вас заинтересует, как Apple пишет свой собственный код.

Если вы проверите частные API, вы увидите, что они везде используют подчеркивания для частных методов. Каждый мир кода Obj-C в iOS использует их. И во многих случаях эти методы проходят через несколько версий iOS без рефакторинга или переименования, что означает, что для них это не временное решение, а соглашение. На самом деле, есть три уровня частных методов, которые они широко используют - без подчеркивания, одиночное и двойное подчеркивание.

Что касается других решений, таких как "private", префиксы имен классов или проектов - они их вообще не используют. Просто подчеркиваю.

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