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 - количество поддерживаемых выходных данных. Немного расширим задачу. Предположим, что количество входных файлов не соответствует количеству выходных. У вас получатся сущности с пустыми методами?

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

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