Использование вспомогательных / служебных методов в классе Factory

У меня вопрос об использовании "служебных / вспомогательных" методов в фабричном классе. Рассмотрим пример строки XML, представляющей документ. У меня есть класс, который преобразует его в «объект» (скажем, PDF, Word, CSV и т. Д.). У меня есть фабричный класс (назовем его DocumentFactory), который принимает эту XML-строку и на основе определенных правил возвращает правильный объект документа.

Мой вопрос здесь в том, что с точки зрения "лучших практик" можно ли мне добавить "служебные / вспомогательные" методы к классу DocumentFactory, которые помогают решить, какой тип объекта будет возвращен? Эти помощники выходят за рамки простых операторов if / swtich case. Но не более 15-20 строк.

Я также использую один частный статический класс в своем коде, и есть около 4-5 вспомогательных методов (помощники являются общедоступными, поскольку у меня есть тесты, написанные для них).

Подходит ли эта установка для фабричного класса?


java design-patterns factory
person RayJ    schedule 20.10.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

person David Seiler    schedule 20.10.2009
comment
Применяются все обычные предупреждения, связанные с методами, что это? - person RayJ; 21.10.2009
comment
Ничего особенного, просто то, что вы уже знаете, если читали своего Фаулера. Не позволяйте этим вспомогательным методам разрастаться до сотен строк запутанной логики, избегайте упорядочивания зависимостей между ними, реорганизуйте их до их собственного класса, если вы обнаружите, что хотите использовать их вне DocumentFactory. Что-то в этом роде. Если у вас есть тесты для них, и эти тесты всеобъемлющие, у вас, вероятно, все в порядке. - person David Seiler; 21.10.2009
comment
Попался. я думаю, у меня все будет хорошо :) - person RayJ; 21.10.2009

arrow_upward
0
arrow_downward

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

person Idris Mokhtarzada    schedule 21.10.2009
comment
Как проверить каждый из частных вспомогательных методов? - person Shaun F; 21.10.2009
comment
Хорошая точка зрения. Если вам нужно протестировать частные методы, я думаю, что проще всего было бы сделать их пакетными методами (или просто полностью и сделать их общедоступными, хотя это не рекомендуется) и чтобы тесты были в том же пакете, что и фабричный класс , но в каталоге test, а не в каталоге src. - person Idris Mokhtarzada; 21.10.2009
comment
именно то, что я пытался выяснить. поскольку служебные методы являются общедоступными, но не присущи классу фабрики (думаю, высокая согласованность), я рассматривал отдельный класс для хранения этих служебных методов и последующего использования этого класса в фабрике. однако мое текущее место работы архаично, и идея использования DI неизвестна даже менеджеру по развитию. без DI я бы добавил ненужный багаж, поэтому решил поместить его на заводе. я рад, что большинство из них согласны с этим здесь :) - person RayJ; 21.10.2009