iPhone: статический метод против sharedManager в Objective-C - PullRequest
3 голосов
/ 03 мая 2010

У меня есть набор функций, которые возвращают часто используемые UIViews в моем приложении, например,

+ (UIView *) getLikeRow:(CGRect) frame ofType:(LikeType) type

До сих пор я использовал статические методы для этого, но недавно я также заметил концепцию sharedManager. Теперь мне интересно, стоит ли мне использовать для этого sharedManager.

Каковы различия и преимущества / недостатки использования статических методов по сравнению с методами экземпляра синглтона sharedManager?

1 Ответ

7 голосов
/ 03 мая 2010

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

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

Применение уникального экземпляра во время выполнения - единственная действительная причина для использования одноэлементного / совместно управляемого шаблона.

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

UIView *theView=[MyViewUtilityClass getLikeRow:aRect ofType:aType];

Это заставляет MyViewUtilityClass вызывать метод из любой точки приложения без инициализации объекта. Это проще и аккуратнее, чем поддерживать уникальный экземпляр. Если вы используете служебные методы в своем приложении, вы можете добавить заголовок в универсальный заголовок .pch, и все ваши пользовательские классы получат служебный класс автоматически.

Однако, как и шаблон синглтона, методы служебного класса могут соблазнить вас стать ленивыми и злоупотреблять ими в местах, к которым они на самом деле не принадлежат. Избыточное использование приводит к тому, что приложение выглядит как старая школа, не объектно-ориентированная коллекция Си независимых функций. Это нарушает инкапсуляцию и модульность и делает вашу программу путаницей процедурного кода.

Итак, будьте осторожны, вы помещаете только самые универсальные и универсальные функции в служебный класс. Если у вас есть много функций, которые имеют дело с определенным классом, таким как UIView и подклассы, то вы должны поместить функции в категорию этого класса.

...