Это когда-либо допустимо для преобразования объекта от базового класса до подкласса
Вы можете использовать метод getParameter () из интерфейса HttpServletRequest.
Например;
public void getMeThoseParams(HttpServletRequest request){
String page = request.getParameter("page");
String goToURL = request.getParameter("gotoUrl");
}
6 ответов
Пока ваша бизнес-модель соответствует вашему домену, вы поступаете правильно.
Однако мне кажется, что у вас должно быть что-то вроде:
Manager Promote(Employee employee)
{
var manager = new Manager();
//promote your employee to a manager here
return manager;
}
внутри какого-то рабочего процесса.
Что касается NHibernate, похоже, вы смешиваете логику ORM с доменом вашего бизнеса. Повышение уровня сотрудника до менеджера - это конструкция предметной области, и как таковая относится к вашей бизнес-модели. Однако то, как NHibernate отображает ваших сотрудников и ваших менеджеров в вашу БД, не имеет ничего общего с вашей бизнес-моделью, за исключением того, как их отображать. Однако это определенно не имеет ничего общего с тем, как повысить сотрудника до менеджера.
В этом случае я бы предпочел композицию наследованию. Если вы будете придерживаться наследования, вы будете менять классы при каждом повышении или понижении в должности и каждый раз, когда вы нанимаете контакт или сотрудник уходит и становится обычным контактом.
Проще просто сказать, что у контактов есть роли. Вы можете добавить к контакту роль менеджера, чтобы повысить его, и удалить роль, чтобы уволить его.
Да, верно. Что касается реализации, вы можете использовать:
- Статический метод для Manager:
общедоступный статический Manager Promote (сотрудник-сотрудник) {...} - Специализированный конструктор для Manager
- Factory или класс обслуживания
I думаю, что любой из этих подходов был бы хорошим решением. Лично мне нравится специализированное конструкторское решение, поскольку оно хорошо представляет реальный мир: вы создаете нового менеджера из существующего сотрудника.
Лично у меня был бы базовый класс со всеми основными вещами и списком ролей.
У каждой роли есть свои свойства и функции.
Имеются два преимущества:
- Легко отдавать или брать роль человеку
- Это позволит вашим людям выполнять несколько ролей без необходимости создавать «комбинированные классы»
Если вы будете использовать одинарное наследование, идущее с наследованием, скоро отобразит вас с такими классами, как "ManagerProgrammer", "ProgrammerStockManager", "ProgrammerSupport"
Добрый день,
Если вы обнаружите, что вам нужно преобразовать производный класс из одного типа в другой производный тип, то это запах того, что исходный дизайн имеет проблемы.
Мои у интуиции такое ощущение, что вы неправильно представляете объект Manager.
Вернитесь к основам и подумайте в терминах объектно-ориентированного программирования, где ваш базовый класс (Контакт) содержит общие элементы объектов Employee и Manager. Любые производные объекты являются просто специализациями базового класса.
В этом случае Manager не является экземпляром Employee?
Оба класса Manager и Employee должны иметь член данных reportsTo, который также имеет тип Employee.
Единственное различие, которое я вижу на данный момент, заключается в том, что объект Manager теперь имеет коллекцию объектов Employee, которые являются их собственными directReports. Вероятно, это должно быть реализовано как указатель на контейнер объектов Employee.
Я не могу придумать какой-либо специализации в поведении, которая требует отделения объекта Employee от объекта Manager.
Хммм, может быть, сделать базовый класс Лицо, которое содержит контактные данные.
Изменить: Извините, из вашего комментария, я думаю, я не достаточно ясно. То, что я описал, не приводит к двум отдельным классам, которые напрямую унаследованы от вашего класса Contact, так что вам нужно изменить экземпляр Employee на Manager во время выполнения, что было вашим исходным вопросом.
То есть, я не думаю, что у вас должно быть два производных класса, Employee и Manager, напрямую унаследованные от вашего класса Contact.
Aren ' В обоих случаях эти типы людей наняты компанией? Почему нужно различать менеджера и сотрудника? Разве Сотрудник больше не Сотрудник, если он становится Менеджером?
Иметь два производных класса, Менеджер и Сотрудник, совершенно неправильно, ИМХО. Вы пытались разбить вещи на понятия «isa» и «has a». Тогда вы увидите, что ваша основная структура неверна.
Сказать, что Сотрудник «isa» Контакт, просто не имеет смысла. Более вероятно, что Сотрудник "isa" Человек и Человек "имеет" набор Контактных данных.
Может быть, унаследовать класс Manager как специализацию Сотрудника? Сотрудник "isa" Person. Менеджер "isa" Employee, который "isa" Person.
HTH
приветствует,
Вы пытались разбить вещи на понятия «isa» и «has a». Тогда вы увидите, что ваша основная структура неверна.Сказать, что Сотрудник «isa» Контакт, просто не имеет смысла. Более вероятно, что Сотрудник "isa" Человек и Человек "имеет" набор Контактных данных.
Может быть, унаследовать класс Manager как специализацию Сотрудника? Сотрудник "isa" Person. Менеджер "isa" Employee, который "isa" Person.
HTH
приветствует,
Вы пытались разбить вещи на понятия «isa» и «has a». Тогда вы увидите, что ваша основная структура неверна.Сказать, что Сотрудник «isa» Контакт, просто не имеет смысла. Более вероятно, что Сотрудник "isa" Человек и Человек "имеет" набор Контактных данных.
Может быть, унаследовать класс Manager как специализацию Сотрудника? Сотрудник "isa" Person. Менеджер "isa" Employee, который "isa" Person.
HTH
приветствует,
Может быть, унаследовать класс Manager как специализацию сотрудника? Сотрудник "isa" Person. Менеджер "isa" Employee, который "isa" Person.
HTH
приветствует,
Может быть, унаследовать класс Manager как специализацию сотрудника? Сотрудник "isa" Person. Менеджер "isa" Employee, который "isa" Person.
HTH
приветствует,
Контакт - это атрибут сотрудника. Рабочий (ваш Сотрудник) - это роль, Менеджер - это роль. Рабочий и Менеджер по-прежнему остаются Сотрудниками, но имеют Роли. Роль - это отношения IS IN, Employee - это отношения AM A, а Contact - это отношения HAS A. У сотрудника есть контакт (отношения 1-1) Один контакт на сотрудника (1-M, если у них два телефона и т. Д., Но я отвлекся) Сотрудник ИМЕЕТ роль (отношения ММ) Многие сотрудники много ролей Сотрудник - это А (отношение M-1) - Многие сотрудники, все сотрудники одного типа.
Итак, вы меняете роли.