spbsmile1. Сделать поддержку разных форматов хранения координат – текстовый, бинарный, xml.

Главное будут смотреть здесь. Тут от вас ожидают использование шаблона "factory method".

заданиеЗадача создать GUI приложение для конвертации файлов данных разных форматов


svenomLeonidvпропущено...

Главное будут смотреть здесь. Тут от вас ожидают использование шаблона "factory method".Ну здрасти приехали. Factory это creational pattern. Что вы тут собираетесь криэйтить? Разумеется, в этом месте надо применять что-то из behavioural паттернов.

GoF перечитай, тот раздел, где про factory method говорится. Если есть обоснованное суждение, почему здесь не подходи фабричный метод - обоснуй.

svenomавторЕсли есть обоснованное суждение, почему здесь не подходи фабричный метод - обоснуй.Обоснование очень простое - тут нечего создавать. Для того, что бы наклепать по одному инстансу "сохранятеля" в XML, текст и т.д.. никакой фактори не нужен.
Я же не зря задание скопировал. У него не только "сохранятель" у него и "считыватель" - классический пример фабричного метода.

spbsmile3. Создать GUI приложение, в котором есть возможность конвертировать файл данных в любой из поддерживаемых форматов. В
Ага, вот тут еще про SwingWorker надо почитать.

Вообще, хорошее задание. Мне нравится - достаточно грамотно проверяет знание Swing и ООП.

svenom2) То, про что вы говорите, называется Abstract Factory, а не Factory Method. Теперь моя очередь рекомендовать вам освежить в голове GoFа.

Не надо за меня говорить, о чем я говорю. Я говорю именно о factory method.

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

У вас нужно сколько конкретных реализаций CoordinateProcessor создать? n^2, где n число поддерживаемых форматов? (XMLtoBinaryProcessor, XMLtoXMLProcessor ... )

По сути. Тут два варианта использования, смотря как делать. Если позволить редактировать данные (в ТЗ этого нет, но я почему-то сразу представил себе табличку), то делаем как-то так (код не Java):



Если же не позволять редактировать данные (т.е. мы при запуске сразу знаем и формат входа, и формат вывода), то можно применить builder, тогда будет как-то так:




Судя по тому, насколько грамотно составлено ТЗ (например, пункт 2 проверяет классическую ошибку новичка, конкатенацию строк вместо использования StringBuilder при считывание текстового файла), работодатель ожидает чего-то, показывающий общий уровень владения ООП.

svenomLeonidv
Все, понял. Вы напрочь не понимаете, что такое фабричный метод, ибо то, что вы привели, это обычный статический метод и все. Даю вам маленький ликбез на эту тему.
Вот пример использования фабричного метода:

А вот его реализация (псевдокод):
Идею улавливаете?
Идею фабричного метода я лет пять назад уловил.
А вы вот почему-то идеи собеседников улавливать не хотите. Ну тогда я разжую:


Мне не нравятся названия XMLData и TXTData, ну да фиг с ним. Контракт Data можно изменить так, чтобы явно показать считывание данных:



В любом случае, предложенное вами решение, требующее n^2 классов, есть пример ужасного ООП.

У меня путаница в названиях. Вместо дата везде читать DataHandler.

svenom Leonidv ,
Ок, тогда уже ближе.
Так изначально было.

svenomОстается вопрос - зачем вы сделали этот метод статическим? Что бы программист никак не смог протестировать зависимый от него класс без наличия реального файла? Пичалька.
Ну сделайте его не статическим. С точки зрения паттернов ООП должен быть именно статический метод. С точки зрения тестирования - обычный, согласен.

По поводу n в квадрате. А у вас какая формула получается для вашего интерфейса? Я свои выводы уже приводил ранее.

svenomНу разумеется нет. Это вы просто на википедии такой пример посмотрели.

В wikipedia я паттерны очень аккуртно смотрю. Там много чего мне не нравится.

svenomBlazkowicz абсолютно верно объяснил, почему статики быть не должно (в реальности - почему ее еколичество должно стремиться к минимуму). Аргумент насчет тестирования для меня вполне убедителен, поэтому тут спорить не буду. Мое решения будет зависит от ситуации. Но я пока не встречал у себя такого, чтобы наличие статичного метода создавало проблемы с тестированием.

Может быть. Только работать со статичными методами зачастую гораздо удобнее, чем с не статичными. Даже google guava вся на статике построена. Аналогично JUnit и еще кучу библиотек можно привести в пример.

svenomФормула? Формула чего? У меня ровно столько же классов, сколько и у вас.
Ровно столько же, сколько у меня не получится. У вас или n классов, или n^m, где n количество поддерживаемых входных данных, m - количество поддерживаемых выходных данных. Немного расширим задачу. Предположим, что количество входных файлов не соответствует количеству выходных. У вас получатся сущности с пустыми методами?

ПМСМ, статичные методы плохи в ООП не тем, что они статичны, а тем, что получается вырожденные классы (без состояния). Примерно ваш случай.

И в любом случае, фабричный метод может быть успешно применён и в вашем дизайне, и в моем.

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 говорю)?
Не вы это задание писали, так что вы не можете сказать, что там ждут. Судя по тому, что эта классическая задача, ждут классического решения, показывающее знакомство с паттернами ООП. Понятно, что любую задачу можно решить кучей способов, возможно что тут вообще можно сделать все без ООП в одной форме и шестью методами. И что?

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