#java #design-patterns #decorator #factory-pattern
#java #шаблоны проектирования #декоратор #фабричный шаблон
Вопрос:
У меня есть фабрика сущностей, которая создает некоторые сущности. У меня также есть объект Person, который создает более конкретных пользователей с помощью шаблона проектирования decorator.
В моем классе factory у меня есть
public class EntityFactory {
private final EntityType entityType;
public enum EntityType{
ENTITY1,
ENTITY2,
PERSON1,
CHILD
}; //I want the user to select only one of those
public EntityFactory(EntityType entityType){
this.entityType = entityType;
}
public EntityType getEntity(){
return entityType;
}
public Entity createEntity(){
switch(entityType){
case ENTITY1: return new Entity1();
case PERSON1: return new Person1(new Person()); //problem
case CHILD: return new Child(new Person()) //problem
//...
default: return null;
}
}
}
Как ENTITY1, так и ENTITY2 расширяют Entity и работают нормально. Когда я пытаюсь создать PERSON1, мне сообщает, что PERSON1 не может быть преобразован в Entity. И это понятно, поскольку IPerson
не существует внутри Entity. Моя проблема в том, как я собираюсь заставить EntityFactory создать конкретного пользователя для меня? Что может быть между этими двумя? В данный момент я делаю повторную проверку шаблона посредника и адаптера. Спасибо за вашу помощь.
Ответ №1:
Ну, является ли Человек сущностью? Судя по вашей схеме, это не так. Если Пользователь расширяет Entity, он будет работать просто отлично.
примечание: У вас есть серьезная причина использовать здесь декоратор? Недостаточно ли наследования?
Комментарии:
1. Я уже пробовал это, и проблема остается. Он не может преобразовать Student в Entity. Причина, по которой я использую Decorator, заключается в том, что сначала я изучаю шаблоны проектирования и хочу узнать о них больше — конечно! — и, во-вторых, я хочу создавать эти объекты динамически во время выполнения, но не все из них. Пользователь должен выбрать между Person1 и дочерним для создания. Видите ли, у них есть некоторые общие методы, и моя логика подсказывает мне, что это более уместно Дочерний элемент — Person2, Person1 и Person2 — это Person, а Person — ЭТО Entity . Я пытался сделать Person сущностью и не получил желаемых результатов.
2. В строке, в которой вы вводите «case person 1», вы возвращаете Person, но в вашем методе указано «общедоступная сущность createEntity()» . Вы можете возвращать только сущность или подклассы сущности.
3. это именно та проблема, которую я хочу решить! Я хочу сделать Person и все его подклассы сущностью, которая также реализует IPerson. Хотя я делаю это сущностью, Person1 не может быть преобразован.
4. разве person1 не расширяет person?
5. Пример пиццы для декоратора идеален. Я ссылался на логику Person1, расширяющую PersonTypeDeterminer. Все, что вам нужно сделать, это научиться правильно комбинировать шаблоны? Вы могли бы попробовать создать фабрику пиццы поверх использования декораторов. Все, что я говорю, это то, что ваш дизайн, возможно, неправильный. Цель UML — представить ваш дизайн простым способом, но ваш дизайн очень запутанный. У Дерека Банаса (автора этого сайта) есть несколько интересных видеороликов ООП. Вы должны понять их более глубоко, прежде чем переходить к шаблонам проектирования.