Распределение кода по as файлам, относящемуся к одному логическому объекту

[Denis_ex]

Есть класс ObjectManager, который парсит/обрабатывает/добавляет объекты в общий список и пр. Кода получается в данном as файле прилично.
Но также еще нужно отпарсить игровой уровень на дополнительные объекты (инструментарий), и этот парсер (напр. ParserTools) получается в пару экранов кода. Хоть его и можно отнести логически и поместить в класс ObjectManager, как набор членов-функций, но я не хочу все громоздить в одном as файле.

Есть вариант вынести дополнительный парсер в другой файл, т.е. в статический класс, синглтон, функцию, унаследовать и пр. Конечно, в данном случае наверно лучше всего подойдет as файл с функцией в котором, также имеются вложенные вспомогательные функции (чтобы разбить код ParserTools на части).

Расскажите, как вы распределяете код по файлам относящийся к одному логическому объекту?

[Aquahawk]

а может сделать пакетом то что сейчас один класс, а в нём соответственно файлы и классы

[goodguy]

Aquahawk, суть вопроса совсем не в этом

[Aquahawk]

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

[expl]

Вроде include из as3 так и не выпилили.
Во Flex-фреймворке можно найти что-то типа:

include "../core/Version.as";

Но не хотел бы я получить класс с include-вставками в поддержку

Есть вариант вынести дополнительный парсер в другой файл, т.е. в статический класс, синглтон, функцию

Хоть убей не понимаю: почему если объект может быть один (и это только предположение) - его обязательно надо сделать синглтоном или статикой?
Сделайте отдельный класс, сделайте у него метод parse(text);
В первом приближении можно создать экзепмляр этого класса внутри вашего божественного объекта, во втором (если потребуется несколько парсеров или тестировать надо будет) - передавать экзепмляр божественному объекту снаружи. Что здесь решать?

[Denis_ex]

Спасибо за ответы.

expl
Ваш вариант – первое, что пришло в голову, но ParserTools не имеет переменных-членов, а ради функции/или разбитой на части вложенных функций, не очень охота создавать отдельный класс и его экземпляр внутри ObjectManager.
Обычно статикой делаются функции типа Math, т.е. набор функций (с передачей параметров) выполняющих свое локальное дело. ParserTools схож, т.к. функция/набор разбитых функций принимает один параметр извне и делает свою локальную задачу.
К слову, статику и синглтон, я сам недолюбливаю (а привел здесь скорее для галочки) и пытаюсь от них избавиться, в основном благодаря использования паттернов.

[andrew911]

Сообщение от Denis_ex

Спасибо за ответы.
К слову, статику и сиглтон, я сам недолюбливаю (а привел здесь скорее для галочки) и пытаюсь от них избавиться, в основном благодаря использования паттернов.

Синглтон это и есть паттерн.
Делайте так, чтобы один класс выполнял одну функцию - SOLID (SRP: Single Responsibility Principle (принцип единственной обязанности))

[mikhailk]

Автор примерно так и делает.
У него просто функция крупновата.

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

[andrew911]

Сообщение от mikhailk

Автор примерно так и делает.
У него просто функция крупновата.

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

Тогда незачем волноваться
Не всегда все умещается в 20 строк

[Denis_ex]

andrew911
>>Синглтон это и есть паттерн.
Верно, я имел ввиду, что заменяю синглтон другими паттернами. Например, некоторые делают доступ к основным данным через синглтон, в данном случае, я использую паттерн Observer (наблюдатель).

andrew911
Спасибо за статью, там приводится хороший пример с классом банковского счета, функционал которого можно логически разделить на три части. Хотя, как подмечено в статье, такой подход является антипатерном ActiveRecord (ну и ладно, я и не привык наделять сущности главенствующим функционалом).
У меня схожая ситуация, т.е. главном классе ObjectManager содержатся: parserObjects (создание обверток-объектов над графикой), parserTools (создание на основе спец граф элементов связей (joints) между физическими объектами, parserButtons (парсинг кнопок различного типа).
Каждый из парсеров имеет 180-250 строк кода.
Сделаю, как советовали в данном топике/статье, для каждого парсера выделю свой класс и создам их экземпляры в ObjectManager. Может быть даже выделю отдельный пакет (как упоминал Aquahawk ) для этих четырех классов.

mikhailk
>>Это я к тому, что уменьшение размера класса и распределение кода по файлам как отдельные задачи не имеют большого смысла при правильном проектировании функционала

Да, но я очень не люблю работать с классом, когда в нем 250-500 строк. В таком коде много функций, которые сразу не так легко разграничить на логические группы и перемещаться по функциям. Особенно проблема остро стоит, когда класс не видел в глаза пару месяцев, даже с комментариями не всегда быстро можно вникнуть.