Действительно ли это непослушно, чтобы иметь большой служебный файл?
Это - то, что мне жаль, что я не знал приблизительно 6 месяцев назад. Я создавал наше первое приложение для iPhone, и я хотел создать простой справочный файл, который был основан на HTML с помощью Контроллера UIWebView.
Однако я не мог выяснить, как встроить локальные изображения, которые я сохранил в Пакете, и я не хотел, чтобы у пользователя должен был быть доступ в Интернет для выборки изображений с сервера.
Мало я знал, что мог сделать следующее для получения изображений от Основного Пакета
NSString *bundlePath = [[NSBundle mainBundle] bundlePath];
NSURL *bundleBaseURL = [NSURL fileURLWithPath: bundlePath];
[webView loadHTMLString:htmlContent baseURL: bundleBaseURL];
, Изображение в HTML может затем назвать локальные изображения непосредственно.
<img src="yourImageFromTheMainBundle.jpg" />
я понятия не имел, что мог установить baseURL с местоположением Пакета.
9 ответов
Если только вы ВСЕГДА будете поддерживать этот материал, то вопрос в том, когда сложность дойдет до точки, когда вы окажетесь в поисках чего-то. Пришло время провести рефакторинг и реорганизацию (реорганизация требует затрат, равно как и отказ от реорганизации).
Если ВОЗМОЖНО, что кто-то еще будет поддерживать проект, включающий ваши утилиты, вы должны учитывать ИХ боль момент при принятии решения о реорганизации. У них НАМНОГО ниже, чем у вас.
Вы хотите разбить его не только по организационным причинам, но и потому, что у вас будет много других файлов, которые зависят от этого. Поскольку все будет зависеть от этого файла, это затрудняет изменение этого единственного файла, поскольку это может вызвать повсеместную поломку.
http://ifaceoughtts.net/2006/04/15/stable-dependencies-principle/
Разделение их на отдельные файлы по категориям (например, графика, строки и т. Д.) Приведет к лучшей организации, облегчению поиска определенных фрагментов кода и уменьшению файлов меньшего размера. вместо одного большого файла.
Я стараюсь разбить их на различные вспомогательные утилиты как вы говорите (graphics_utils), когда это становится уместным.
Разбейте его. Материал будет легче найти, его легче использовать повторно, легче рефакторинг, проще модульное тестирование. Недавно мне потребовалось получить набор методов обработки дат ISO-8601 из огромного служебного класса статических методов Java, и было действительно трудно найти 5% необходимого мне кода.
Это определенно не кошерно, потому что следующий парень, который прочитает ваш код, не будет знать, где что-либо искать. Разделите его по функциям, и ваши коллеги будут вам благодарны!
Как и все, я бы их разбил. Но сейчас я предпочитаю использовать методы расширения, поэтому у меня будет один класс (и один файл) для каждого расширяемого класса (например, StringExtensions , SqlDataReaderExtensions и т. Д.). Я считаю, что это хорошо разбивает служебные методы.
Еще одно преимущество, которое дает разбиение файла на отдельные части, заключается в том, что когда вы помещаете его в систему контроля версий, вы можете получить более детальный контроль. Это действительно полезно, если у вас есть биты, которые часто настраиваются / расширяются / специализируются, и другие биты, которые относительно стабильны.
Другой момент: вы должны организовать свой код, т.е. е. разбейте его на более мелкие модули и классифицируйте, потому что в какой-то момент вы в конечном итоге напишете вторую и третью функции для того же самого, просто по той причине, что вы не найдете ту функцию, о которой вы знали, но вы не помню его имени.
У меня есть (довольно большой) проект с таким модулем и есть программная логика, для которой существует до 5-6 реализаций (для одного и того же).