2013-03-15 4 views
2

Я новичок в объективе-c, и у меня есть вопрос архитектуры или дизайна. Я создаю приложение ios и, как и большинство приложений ios, использует различные цвета, шрифты, шаблоны и т. Д. Возможно, я в настоящее время неправильно нахожу код, но я переписываю такие вещи, как настройки цвета. И в результате меняющиеся цвета становятся упражнением по нахождению всех настроек цвета в коде, их переписыванию и т. Д. Кажется, мне неэффективно.Использование одноэлементного метода для создания базового класса вспомогательного класса

Например, я использую темно-красный цвет в нескольких местах в своем приложении. Я часто предпочитаю писать метод [UIColor colorWithRed ...]. Тем не менее, мне интересно, если создание синглтона, возвращающего мои пользовательские цвета (как UIColor), является разумным подходом к «модуляции моего пакета стиля». Таким образом, я мог бы написать что-то вроде этого

[label setTextColor:[[MyStyleSingletonClass sharedStyler] myDarkRed]]; 

Таким образом, если дизайнеры вдруг хотят myDarkRed быть сенсорным темнее, изменить его один раз, и это хорошо идти через приложение. Очевидно, что стиль и UX больше, чем цвет, но мне любопытно, имеет ли этот подход смысл или если я настроюсь на проблемы в будущем. Или, возможно, эта возможность существует в объективе-с уже, и я не вижу смысла. Заранее спасибо.

ответ

8

Я думаю, что лучший подход к чему-то подобному - это категория методов класса на самом UIColor. Я часто пишу категории цветов для проектов с большим количеством пользовательских цветов.

Что-то вроде этого:

// UIColor+AppAdditions.h 
@interface UIColor (AppAdditions) 

+ (UIColor *)myDarkRed; 

@end 

// UIColor+AppAdditions.m 

#import "UIColor+AppAdditions.h" 

@implementation UIColor (AppAdditions) 

+ (UIColor *)myDarkRed 
{ 
    return [UIColor colorWithRed:0.1 green:0.0 blue:0.0 alpha:1.0]; 
} 

@end 

Таким образом, вам не нужен весь Singleton и его более портативный упаковывают одноэлементные делают другие вещи. И вы можете получить доступ к чисто цвета, как это:

[label setTextColor:[UIColor myDarkRed]]; 

Примечание

Как отметил Роб и Павла. Лучше назвать их соответствующим образом. Я взял имя, которое у вас было, но лучше было бы назвать их специально для их использования и следовать правилам, таким как префикс и суффикс.

+0

Очень хорошее мышление, хотя :) Удивительно иметь согласованную цветовую схему во всем приложении и иметь что-то подобное действительно реально помогает. –

+1

Я также часто использую категорию. Однако одно преимущество для объекта «стиль» заключается в том, что его можно заменить во время выполнения, чтобы изменить стиль. Например, вместо «myDarkRed» часто бывает лучше иметь такие методы, как «errorColor», и это то, что может потребоваться изменить. (Но я часто по-прежнему использую подход категории, так как это так просто, я просто делаю 'errorColor' метод на' UIColor'.) –

+2

Я поклонник подхода категории и соглашаюсь с @RobNapier по наименованию цвета для его использования а не фактической реализации (где это возможно). Что-то, что следует учитывать, так это то, что часто лучше придерживаться последовательного стиля именования - в этом случае после 'UIColor' оно должно быть' Color'.Еще один момент при именовании заключается в том, что вы должны использовать префикс для методов, добавленных с категорией, чтобы избежать столкновений имен методов, например. Я могу закончить с помощью 'pas_lightBackgroundColor'. –

4

Почему бы не использовать macro?

в YourHelperClass.h

#define DARK_RED [UIColor colorWithRed:0.1 green:0.0 blue:0.0 alpha:1.0] 

и вы можете использовать, как это (не забудьте импортировать YourHelperClass.h):

[label setTextColor:DARK_RED]; 

Я думаю, что это более эффективно использовать macro

+0

Я второй использую макрос для этого. Таким образом, Styles.h можно легко использовать для цветов, шрифтов и т. Д. Подход к категории означает, что только цвета могут быть сохранены в категории «UIColor + Style» - не говоря уже о том, что это более подробный. – cleverbit

Смежные вопросы