Полезные методы в объективе-с

Question

Где я должен разместить служебные методы в target-c?

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

Я видел примеры, когда они помещаются в основной файл appdelegate и поэтому доступны всем. Хотя это кажется мне немного странным ...

Answer 1

У вас есть несколько вариантов:

• Самый простой подход состоит в том, чтобы иметь набор функций C для общих задач (если вы используете расширение .m, вы можете использовать объекты Objective-C в своих функциях C). Например, из вашего кода вы могли бы позвонить showAlertDialog().
• У вас может быть «служебный класс» с кучей методов класса, которые вы импортируете в каждый файл. Так, например, вы могли бы позвонить +[MyUtilities showAlertDialog]. Это наиболее прямой эквивалент статических служебных классов, скажем, Java, но немного неуклюжий в Objective-C.
• Другой вариант, как сказал Пол Линч, - использовать категории для расширения общих классов. Единственная проблема заключается в том, что это может привести к проблемам с ремонтопригодностью. Он также работает только для расширения уже существующих классов и только тогда, когда вам не нужен доступ к ivars. У вас может быть категория для NSObject, которая сделает методы доступными для всех ваших объектов, но я настоятельно рекомендую против этого (это может привести к серьезным проблемам с удобством обслуживания).

Лично я использую сочетание вариантов 1 и 3. Когда у меня есть функциональность, которая явно связана с конкретным существующим классом, я использую категории. В противном случае я использую функции Си.

Answer 2

Да, это довольно странно (и плохая практика).

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

Это зависит от методов и того, где они вписываются в общую структуру приложения (и всегда MVC стоит за вещами).