Object Oriented CRUD program - What is the reason for the OO design?_问答_开发者

First of all, I really don't want anyone to do my assignment. I just can't understand the point of the design that I've been asked to implement. One of the methods seems redundant to me and I wonder if someone could shed some light on it.

I have to make a Student class (and subclasses) that has 4 methods: add, delete, update and query. I have to be able to use those methods to update a database. For example the spec for the add() method says:

When this method is called, the database entry for the student is created.

I can understand that we need to have a class here because if the information entered into the GUI is incorrect, then I can have some setter methods in the Student class that will throw an exception that can be caught by the GUI and these can be displayed. So the class is useful to validate the information. Likewise for the update and delete methods.

The thing that is really annoying me is the query() method:

When this method is called, a query is made to the database to retrieve the information and is then printed to the screen.

The Student class is meant to have a query() method (and it has subclasses that inherit this as well). But in order 开发者_运维技巧to query the database, we already need to have the instance created, so we'll already have queried the database in order to get the info to create the class, so I could just as well call the toString() method that I've overridden to display the class's data.

I don't see the point of each Student instance having a query() method when it will be redundant for them to use it. Can anyone tell me why this might be useful?

Thanks

Update

Thanks to everyone who answered. I take on board the fact that there should normally be a separation of concerns between the object that holds data and an object that uses or acts upon that data.

My assignment states that the query method should query the database and then display that info to screen. I'm thinking now that if I made this a static method and gave it an argument of the student name or something, then it could actually query the database and then create a Student instance with that info and display it. At least that makes sense to me in that it's only called once, so there's no redundancy.

First off: I'd consider it a very bad design if the Student class is both the value holder and the class that handles loading/storing. It violates the single responsibility principle. I'll assume that this is homework and thus overlook this part for now. The same problem exists with the query() method: it seems to have two responsibilities for no apparent reason.

When writing an object-relational mapper (which you are kind-of doing here), it is often the case that you have "half-restored" objects: Objects which you know should exist in the database and you know their primary key (for example because you have a reference to that object in another object).

In that case it could easily be the case that a query() method that loads the actual data could be useful.

It is not useful and no one would (or should) do it like that. A Student is a persistable entity, but some other component will be responsible for creating, reading, updating or deleting those entities.

Often we see designs that consist of data transfer objects (a value holder, the *entity bean, your Student) and factories that do the CRUD business.

Ask yourself (or the teacher), what do you expect from a query method on Student? I'd expect some sort of query, where a student executes to get more informations for his/her studies.

The purpose for this is that the Student object should not be inextricably tied to a Student record. I should be able to create a new Student object that is empty, and does not have a unique ID yet.

Perhaps I want to create a new Student that doesn't exist yet in the system, I can provide the necessary data, call my add() or insert() method and then this will be persisted. Likewise if I create a Student object and call query() I imagine that the object values will all be replaced with the result of the fetched Student record.

As others here have noted, it is not considered a popular practice for the Value Holder, the entity itself to have the CRUD functionality built within. This doesn't necessarily mean that this is inherently wrong. In OOP, the object should have all functionality associated with itself and it would be more similar to an EJB EntityBean than your typical ORM/Persistence Framewok Bean that is more popular today.

The ORM/Persistence Framework that other answers have stated is known as an Anemic Data Model which certain OOP evangelists like Martin Fowler decry. http://martinfowler.com/bliki/AnemicDomainModel.html