when building database appliaction,some articles suggest using value object to store imformation querying from the database.
if one row in a table is stored in a value object, there may be some redundancy.for example,if a value object have ten attributes,but in some situation I need two of them and in another case I may need three of them.
my question is why they still suggest us to use value object?If I only need two attributes,but get all

when building database appliaction,some articles suggest using value object to store imformation querying from the database.
if one row in a table is stored in a value object, there may be some redundancy.for example,if a value object have ten attributes,but in some situation I need two of them and in another case I may need three of them.
my question is why they still suggest us to use value object?If I only need two attributes,but get all attributs,obviously,there is a waste of memory.

Hi
I think you should use more types of value objects, each one containing exactly what you need:for example only 2 attributes, not 10.
Best regards, Mircea

I think u really need to evaluate the memory overkill that this will cause.

If its just a combination of 10 attributes that u need everytime, then its not really going to be a big deal if u use a value object having all 10 attributes.

Just think of the time that u will save having a general value object, as opposed to forming and saving multiple types of value objects with different combinations of the attributes.

It is about absolutely about reusabilty.

In case u really wanna restrict the accessors then, u cud use the same class that implements different interfaces, each corresponding to a diff set of attributes. Altho this is a very dirty way to do it.

Hope this helps.
Cheers
Ajay

I would recommend starting out by using a value object. First, it gives your data-manipulation methods a consistent, easy-to-understand interface (for example, if you're designing a personnel management system, all your methods are dealing with Employee objects). Second, it makes it easy to create links between different methods, or "helper" methods -- especially useful when you didn't anticipate the need up front. You're basically trading off a bit of extra memory for a boost in the ease of creating (and using) your API. If you find that the system uses too much memory, THEN refactor and optimize it. I'd go for ease-of-programming and ease-of-use first, and worry about the optimization second. It may not even be necessary to optimize it.

Another approach would be to use a value object for the method signatures, but not always populate all its fields. For example, if you might only populate the ssn and vacationDays fields of an Employee object, if that's all your method will be using, but still use an Employee object as the method parameter. That keeps the consistent API, gives you the flexibility to populate more fields if it becomes necessary, and keeps you from wasting memory on filling fields you don't need (e.g. employee photo, for example).