Полиморфная фабрика/getInstance() в Java

Статический метод определен в родительском классе и также вызывается статически. Таким образом, в методе нет возможности узнать, что вы вызвали его в подклассе. Компилятор Java, вероятно, даже статически разрешает вызов в вызов родительского класса.

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

Ознакомьтесь с методом EnumSet.noneOf(). У него такая же проблема, как и у вас, и он решает ее, передавая метод java.lang.Class. Вы можете использовать newInstance в классе. Но лично я бы просто использовал фабричные объекты, а не классы со статическими методами.

Вы смотрели в Guice? Не уверен, что это точно решит вашу проблему, но он действует как универсальный контейнер для инъекций фабрики и зависимостей и устраняет нетиповые безопасные строковые ключи.

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

используйте интерфейс, такой как:

Public Interface Node<T> {
  public Object<T>    getObject();
  public String       getKey();
  public List<String> getDependencies();
  public void         addDependence(String dep);
}

а затем используйте фабрику для создания экземпляров узлов

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

Таким образом, вам также не нужно знать, какой класс на самом деле был возвращен с фабрики.

Я бы также, вероятно, сделал «MyClass» интерфейсом, если вы рассматриваете шаблон Factory.

Класс Class параметризован типом экземпляра, который он может создать. (пример: Class‹String› — это фабрика для экземпляров String.)

Я не вижу никакого способа обойти знание типа экземпляра, который должен быть создан, когда вы getOrCreate используете фабричный метод здесь, поэтому я бы рекомендовал передать его методу и параметризовать генерируемый тип:

private static Map<String, MyClass> directory = new HashMap<String, MyClass>();

public static <T extends MyClass> T getInstance(String name, Class<T> generatorClass)
{
  MyClass node = directory.get(name);    
  if(node == null) {
    node = generatorClass.getConstructor(String.class).newInstance(name);
    directory.put(name, node);
  }
  return node;
}

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

public static MyClass getInstance(String name) {
  return getInstance(name, MyClass.class);
}

Вы, вероятно, хотите внедрение зависимостей. Это несколько обобщило бы то, что вы пытаетесь сделать.

Кроме того, Наследование, вероятно, тоже не совсем то, что вам нужно. Никогда не используйте его, если вы не можете пройти тест «есть-а». Если ваш унаследованный класс "Имеет" уникальный строковый тег (по сути, это то, чем кажется ваш класс), это не означает, что он "является"...

Хотя можно было бы, чтобы один держал другого. Вероятно, существует довольно много решений, но A) вы не опубликовали весь список требований, поэтому мы можем только догадываться, и B) то, что вы, вероятно, хотите, это внедрение зависимостей. :)

Шаблон выглядит как своего рода приспособленец (структурно, если не идеальное совпадение намерений.)

Метод populate, как описано, можно сопоставить с шаблоном Template, хотя он не обязательно устраняет выраженные опасения.

То, что я предлагаю, является обобщением фабрики с методом create (вместо getInstance, который во всяком случае для меня подразумевает Singleton) для различных типов, которые вы ожидаете.

public static MyClass createJavaNode(String name, <differentiator>);
public static MyClass createSqlPlNode (String name, <differentiator>);
.
.
.

Знание того, как name сопоставляется с <differentiator>, на самом деле зависит от реализации. В идеале должен быть полиморфный create и дифференцирование по node типу. Метод create возвращает MyClass, но на самом деле возвращает подклассы. Я настоятельно рекомендую сделать MyClass либо интерфейсом, либо абстрактным классом с методом abstract populate (есть Template).

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

Перефразируя Р. А. Хайнлайна, TANSTAAFL — бесплатного обеда не бывает — где-то в приложении должны существовать знания о том, как создавать различные типы. Таким образом, ваш выбор состоит в том, чтобы поместить это знание в класс Factory, как было выражено в некоторых других ответах, или отделить решение о том, какая реализация создается от как она создается. созданный. Вроде есть возможность сканировать файловую систему и собирать из нее Nodes. Этот код будет (или может) знать тип Node (ответ на вопрос что), который должен быть создан.

Будет ли это реализовано как switch или в более объектно-ориентированном стиле (один из случаев, когда диспетчеризация на основе таблиц была бы хорошей) зависит от вас. Если это что-то, что может быть полезно, я могу расширить это здесь.

Кстати, если основное поведение MyClass необходимо расширить или изменить для некоторых подклассов, именно здесь может пригодиться Decorator.

Оригинальный ответ:

Вы можете использовать Decorator или Шаблон Шаблоны проектирования в качестве альтернативы.