Question about object-orientation

Question

Hi all,

I had this questions since the time I learnt about object-oriented programming. Now, I have got a wonderful forum I thought of asking this.

Lets say we are implementing an employee management application using EJB.

Now, there are 2 ways of doing this.

1. Normally, we create entities (POJOs) which represent an employee. Then we create an EJB interface 'EmployeeManager' with add, delete, update, retrieve, retrieveAll methods. This way I could use 'employee' entity as a data transfer object.

2. We call the EJB interface itself 'Employee'. Implementation could be called 'EmployeeImpl' which has fields as well as method implementation (add, delete, update, retrieve, retrieveAll). If I am using a layered approach where my business logic needs access to employee details, I need to pass 'EmployeeImpl' (because it contains values).

Which one do you think is the better way?

I prefer the first one, because it 'looks' fine and does not feel awkward. like

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

Where as the second one would look like (though I am not sure),

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

As you can see, the second one looks awkward.

I request you guys to advise me on this.

Thanks manju

Answer 1

The first one is certainly clearer, and clarity should certainly be an aim of your code. However, in terms of the first one, I'll direct you here: Jeff Atwood's take on calling things "SomethingManager" - not recommended.

Answer 2

Of your examples, I would not recommend #2, because it gives the Employee class too many responsibilities.

Although not giving a straight answer, I can cordially recommend Martin Fowler's book Patterns of Enterprise Application Architecture. It has been a great eye-opener for me personally, and describes several different approaches to this.

I also think the open-source Hibernate is a great tool for persisting entities. I'm sure you will find lots of good input there.

Answer 3

Having separare class for persisting Employee looks more OO. And more flexible, because you potentially may want to have DBEmployeeMrg, FileSystemEmployeeMrg, InMemoryEmployeeMgr and MockEmployeeMgr for testing - all those classes may implement inteface EmployeeMrg in different way.

For your code to be shorter you may want to have employee being able to save itself - employee.save() instead of employeeMrg.save(employee) I can understand design when employee saves itself, updates and even deletes, but definitely one employee is not needed to load another employee by id and to load list of employees.

Answer 4

Strive for appropriate design and not "OO Compliance".

Incidentally, EJB is not Object Oriented at all.

The best practice for using EJB is:

• DataContainer classes hold data you got from the DB or the user; "POJOs"
• EJBs have methods that operate on your DataContainers
• DAOs handle persisting/retrieving DataContainers from the database.

EJBs typically do not have fields unless they are to be deployed as Stateless, which is needed only rarely.

If you are using EJBs that would be the design most people would expect. It is clearly not OO, as the DataContainers contain no real methods and the EJBs/DAOs contain no real data.

This is not a bad thing; it separates concerns and makes your system more changeable and maintainable.