Сегментирующий код в несколько исходных файлов

Question

Я часто читал о желательности разделения больших (монолитных?) Блоков кода приложения на отдельные файлы исходного кода, чтобы упростить их поддержку и т. Д., Но я еще не видел что-то объясняющее, как это сделать.

Процесс создания отдельных файлов достаточно прост при добавлении подкласса, конечно, и это хороший пример того, что я пытаюсь достичь, но что, если у нас есть только один объект контроллера, и мы хотели разделить наш код в том, что: (1) группа файлов интерфейса и реализации, содержащая только , только методы вычисления вещей и (2) еще одна пара, содержащая только методы, связанные с печатью, но каждый метод может иметь доступ ко всем другим методам, как если бы они все были в одном (исходном) файле.

Любые подробные советы о том, как это сделать (если это возможно), будут высоко оценены. Спасибо :-)

Answer 1

Это лучше всего сделать с помощью категорий. Например, создайте файл заголовка с именем MyController + Printing.h:

#import "MyController.h" 
@interface MyController (PrintingSupport) 
- (void)print:(id)sender; 
@end 

и файл реализации MyController + Printing.m:

#import "MyController+Printing.h" 
@implementation MyController (PrintingSupport) 
- (void)print:(id)sender 
{ 
} 
@end 

Посмотрите в файлы заголовков от Apple для больших примеров этой техники.

Answer 2

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

Однако существуют ситуации, когда вам необходимо поддерживать совместное использование множества данных и функциональности между модулями, что звучит так, как вы хотите. Например. в GUI-программировании модель проектирования модели-контроллера-контроллера делает именно это. Ключ состоит в том, чтобы группировать ваши данные и выполнять какие-либо другие действия, но это намного менее удобно.

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

Answer 3

Если ваши классы растут настолько большими, вы думаете о том, как их вырезать в отдельные исходные файлы, у вас, вероятно, есть проблема с дизайном.

Модельный дизайн-контроллер (лучше, модель-контроллер-вид) создает небольшой модульный код почти автоматически.

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

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

Весь хороший дизайн начинается с модели данных. Модель должна обрабатывать все логические отношения с данными, т. Е. Создавать, изменять, проверять, сохранять и т. Д. Правильно спроектированная модель данных полностью агностична в отношении пользовательского интерфейса. В идеальном случае модель данных должна работать со стандартными представлениями, веб-просмотрами, командной строкой или выгружать URL-адрес.

Я всегда начинаю проект, создавая модель данных в тестовом приложении с абсолютным минимальным интерфейсом. (Часто это просто пустое приложение, которое запускается, программно управляет моделью данных, печатает на консоль и завершает работу.) Только когда модель данных работает независимо, я перехожу к остальной части программы.

Теперь, когда я понимаю операции с данными и данными, я могу создать пользовательский интерфейс для каждой среды, в которой я буду работать. Пользовательский интерфейс понимает только, как создавать элементы пользовательского интерфейса и как реагировать на события. Он не содержит никаких данных или даже логики, связывающих элементы друг с другом.

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

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

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