Java: Использование одного класса для генерации объектов другого

Question

У меня есть два класса. SpeciesReader принимает файлы и анализирует их. Species хранит определенные данные о разновидности, которая была проанализирована из файла.

В настоящее время у меня есть метод: SpeciesReader.generateSpecies(), в котором используется файл, с которым он был создан для создания объекта Species. Это плохая практика/дизайн? Должен ли я каким-то образом найти способ переместить это в конструктор в Species, который принимает имя файла в качестве аргумента?

Answer 1

Совсем нет. Это общий шаблон, называемый фабрикой.

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

Что касается того, должна ли эта ответственность идти по видам, это зависит от характера файлов. Если файл содержит только один вид, и нет больших накладных расходов при загрузке этого файла, тогда имеет смысл сделать его частью Видов.

Но если файл содержит много видов или стоит дорого инициализировать, то имеет смысл переносить эту ответственность на другой класс и нести ответственность за создание объектов видов.

Answer 2

Есть несколько моделей вы можете использовать:

• Proxy
• Abstract Factory
• Strategy

Выбор, какой шаблон для реализации будет зависеть от случая использования, но Клетус является Правильный, завод кажется хорошим выбором.

public class SpeciesFactory 
{ 
    private final static SpeciesFactory INSTANCE = new SpeciesFactory(); 

    private SpeciesFactory() { } 

    public static SpeciesFactory getFactory() 
    { 
     return INSTANCE; 
    } 


    public Species getSpecies(String filename) 
    { 
     Species species = null; 
     //do business logic 
     return species; 
    } 

} 

Вы могли бы использовать его, вызывая Species плотоядных = SpeciesFactory.getFactory() getSpecies ("carnivore.txt").

Answer 3

У вас есть пример Factory Method Pattern. В некоторых случаях это может быть использовано в creational pattern. Мое личное предпочтение, однако, состоит в том, чтобы попытаться ограничить его использование только тем, что доступно для более читаемой замены для ctor, и не делать в нем слишком много сложного. Это упрощает тестирование любых классов, которые зависят от этой фабрики.

Для чего-то сложного строительства я бы использовал Abstract Factory. Таким образом, я могу тестировать компоненты с зависимостью от указанной фабрики, не создавая кучу файлов и любых других зависимостей, которые есть на заводе.

Выше вы спрашиваете о наличии Singleton против статического метода на заводе. Я беру на себя следующее: статический метод хорош для читаемых ctors, синглтон хорошо раздражает любого, кто предпочитает unit testing.

Answer 4

Это хорошая идея, чтобы разделить синтаксический анализ файла с реализацией объектов, проанализированных из этого файла. Это называется «Разделение проблем». Внедрение видов не должно знать и не заботиться о том, как оно представлено в постоянном хранилище (в конструктивном жаргоне OO это должно быть «агностичность настойчивость») или откуда передаются параметры, переданные его конструктору. Он должен заботиться только о том, как взаимодействует с другими объектами в системе, когда он был создан, однако это происходит.Забота о том, как виды представлены в постоянном хранилище, должна быть реализована в другом месте, в вашем случае в SpeciesReader.

Answer 5

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