Вопрос об объектно-ориентированности

Question

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

Допустим, мы внедряем приложение для управления сотрудниками с использованием EJB.

Теперь есть 2 способа сделать это.

1. Обычно мы создаем объекты (POJO), которые представляют сотрудника. Затем мы создаем EJB-интерфейс EmployeeManager с методами add, delete, update, retrieve, retrieveAll. Таким образом, я мог бы использовать сущность «сотрудник» в качестве объекта передачи данных.

2. Мы называем сам интерфейс EJB «Сотрудник». Реализация может называться EmployeeImpl, который имеет поля , а также реализацию метода (добавить, удалить, обновить, получить, получить все). Если я использую многоуровневый подход, где моей бизнес-логике нужен доступ к данным сотрудника, мне нужно передать «EmployeeImpl» (поскольку он содержит значения).

Как вы думаете, какой из них лучше?

Я предпочитаю первый, потому что он «выглядит» хорошо и не чувствует себя неловко. как

EmployeeMgr empMgr = // JNDI lookup;
Employee emp = new Employee();
empMgr.add(emp);
Employee employees[] = empMgr.retrieveAll();

Где будет выглядеть второй (хотя я не уверен),

Employee emp = // JNDI lookup;
emp.setName(); //set the properties
emp.add();
Employee employees[] = emp.retrieveAll();

Как видите, второй выглядит неловко.

Прошу вас, ребята, посоветовать мне это.

Спасибо мандзю

Answer 1

Из ваших примеров я бы не советовал # 2, потому что это дает классу Employee слишком много обязанностей.

Хотя я и не даю прямого ответа, я могу сердечно рекомендовать книгу Мартина Фаулера Шаблоны архитектуры корпоративных приложений . Лично для меня это стало большим откровением и описывает несколько различных подходов к этому.

Я также думаю, что Hibernate с открытым исходным кодом - отличный инструмент для сохранения сущностей. Я уверен, что вы найдете там много хорошего.

Answer 2

Стремитесь к соответствующему дизайну, а не к «OO Compliance».

Между прочим, EJB вообще не является объектно-ориентированным.

Лучшая практика использования EJB:

• Классы DataContainer содержат данные, которые вы получили от БД или от пользователя; "POJOs"
• EJB имеют методы, которые работают с вашими DataContainers
• DAO обрабатывают сохранение / извлечение DataContainers из базы данных.

EJB обычно не имеют полей, если только они не должны быть развернуты как Stateless, что требуется очень редко.

Если вы используете EJB, это будет дизайн, которого большинство людей ожидают. Это явно не OO, так как DataContainers не содержат реальных методов, а EJB / DAO не содержат реальных данных.

Это не плохо; это разделяет проблемы и делает вашу систему более изменчивой и обслуживаемой.

Answer 3

Первый, безусловно, яснее, и ясность должна быть целью вашего кода. Однако, с точки зрения первого, я направлю вас здесь : Джефф Этвуд берет на себя вызовы "SomethingManager" - не рекомендуется.

Answer 4

Наличие отдельного класса для сохранения Сотрудник выглядит более OO. И более гибкий, потому что вы потенциально можете захотеть иметь DBEmployeeMrg, FileSystemEmployeeMrg, InMemoryEmployeeMgr и MockEmployeeMgr для тестирования - все эти классы могут реализовывать inteface EmployeeMrg по-разному.

Чтобы ваш код был короче, вы можете захотеть, чтобы сотрудник мог сохранять себя - employee.save () вместо employeeMrg.save (employee) Я понимаю дизайн, когда сотрудник сохраняет себя, обновляет и даже удаляет, но определенно одному сотруднику не нужно загружать другого сотрудника по идентификатору и загружать список сотрудников.