svenomLeonidvМожет быть. Только работать со статичными методами зачастую гораздо удобнее, чем с не статичными. Даже google guava вся на статике построена. Аналогично JUnit и еще кучу библиотек можно привести в пример.Все верно, удобнее. Только вы не учли один момент - удобнее, когда эти статичные методы присутствуют в уже готовой библиотеке, которой вы пользуетесь - т.е., которую вы точно не будете менять, тестировать и поддерживать. И как раз ваши примеры - Guava, JUnit - это вспомогательные библиотеки, это не бизнес-логика. Поэтому им простительно, так же, как и


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

svenomLeonidvРовно столько же, сколько у меня не получится. У вас или n классов, или n^m, где n количество поддерживаемых входных данных, m - количество поддерживаемых выходных данных. Немного расширим задачу. Вы что-то не так считаете. Если у нас n входных типов и m выходных, то у меня будет DISTINCT (n OR m) - то есть столько классов, сколько уникальных типов данных есть.

Угу. Изначально просто n = m, поэтому у вас n классов.

svenomLeonidvПредположим, что количество входных файлов не соответствует количеству выходных. У вас получатся сущности с пустыми методами?Предположил - не получилось. То есть, например, мы должны читать из XML, но не можем в него писать? Если даже так, то реализовать запись это несколько строк кода, ибо основная сложность - это всякий хлам для сериализации/десериалиазции, который так и так придется писать.

Например так. Только не XML, а какой-то другой формат. Запись, как правило, делать легче, чем чтение. Так что измените пример - надо считать из большего количества классов, а записать в меньшее.
svenomLeonidvПМСМ, статичные методы плохи в ООП не тем, что они статичны, а тем, что получается вырожденные классы (без состояния). Примерно ваш случай.То есть stateless-классы это по умолчанию плохо? У вас работа с БД, например, считывание - всегда stateful?

Скорее всего, как и у вас. Настройки к СУБД у вас же не прописаны в каждом DAO, а получаются из соединения или еще как.


svenomА сервлеты у вас все stateful? А stateless бины из EJB - это тоже плохо? Stateless - это просто один из подходов к реализации сервисов, не большое. Он не плохой и не хороший, он просто решает свои задачи. И на уровне бизнес-логики stateless-сервис, прикрытый интерфейсом, всегда лучше, чем статический метод, так как:
1) Мы достигаем слабое связывание - пользователи сервиса не зависят от его конечной реализации
2) Мы можем легко вставить заглушку на этот сервис в unit-тестах.
А в случае static-методов мы намертво привязываемся к реализации метода и никак не можем от него избавиться.

С этим согласен.

svenomLeonidvИ в любом случае, фабричный метод может быть успешно применён и в вашем дизайне, и в моем. Может. Вот только необходимость его использования далеко не очевидна. От автора ожидают в первую очередь умение работы с файлами, с XML, с серилазацией, с потоками, понимание понятия "интерфейс", а не применения паттернов с непонятной целью
Сериализация в этой задачи абсолютно лишняя. Что там сериализовывать (я про интерфейс serializable говорю)?
Не вы это задание писали, так что вы не можете сказать, что там ждут. Судя по тому, что эта классическая задача, ждут классического решения, показывающее знакомство с паттернами ООП. Понятно, что любую задачу можно решить кучей способов, возможно что тут вообще можно сделать все без ООП в одной форме и шестью методами. И что?

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