Enthuware

I'm a bit confused by this one.

How does defining an interface containing the signatures of the CRUD methods remove them from the business logic? Surely they still have to be implemented within that business logic in this case?

No, usually CRUD methods are not considered business logic. They merely have the logic for storing and retrieving entities, which depends on the database. That is why these methods are separated out from the the business logic (which determines what to do with those entities).

HTH,
Paul.

Hello,

I'm bit confused too with this question in what creating an interface apply a DAO pattern to this class ?
Because even if I create an interface I have to create a concrete class implementing this DAO, the result is 2 classes :
one with get/setName et get ID (1st answer)
another one with find, save, remove, update (2nd answer)

For me only the 2 first answers are right.

Moreover implementing the interface doesn't mean create to different classes.

DAO for an entity contains the create, remove, update, and delete (CRUD) methods for that entity. So to create a DAO for Student entity, you need to create a class that contains implementation for these methods (option 2) and an interface with the CRUD method declarations (option 3).

Option 1 is not correct because you don't move setters and getters out of Student class to create DAO.
HTH,
Paul.

I agree with the CRUD but if you move setter and getter out from Student, the resultant class comply with he DAO "CRUD" pattern no ?
Creating an interface according to the question doesn't apply DAO pattern to this class.
The question : "What do you need to do to apply the DAO pattern to this class?"

DAO pattern involves at least 3 classes. The entity class, the DAO interface, and the DAO implementation. The given code is only for one class and as the name suggests, it is the entity class. So the CRUD methods need to be moved out of this class.

If you move accessor method out of this class, it would still not comply with DAO pattern because then name would be inappropriate.

HTH,
Paul.

ok I understand now, thanks for your answer

The class is Student, okay....could be an entity class!
Never a DAO class!

What do you need to do to apply the DAO pattern to this class?
Then, "...Move find, save, remove, and update methods to another class...." THE DAO CLASS!

Refactoring a class by "applying" a pattern to that class doesn't necessarily mean that class will be the "dao" class! If you are refactoring a class into multiple classes, obviously, only one class will be dao and other will be entity. The question does not ask you to convert Student class into a DAO class. It is asking you to apply the DAO pattern.

Can't that be a more generic answer for the interface part ? Or do you see a hitch somewhere ?

public interface CrudDAO<T>{
    public T find(int id);
    public void save(T t);
    public void remove(int id);
    public void update(T t);
}

and then

public class StudentCrudDAO implements CrudDAO<Student> {
  //Implementation for the interface methods.
}

public class TeacherCrudDAO implements CrudDAO<Teacher> {
//Implementation for the interface methods.
}

...

Yes, that is possible as well.