aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes ValueObject pattern question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "ValueObject pattern question" Watch "ValueObject pattern question" New topic
Author

ValueObject pattern question

Sudheera Liyanage
Greenhorn

Joined: Oct 14, 2002
Posts: 7
Hi,
I want to know whether a ValueObject can have validations
inside methods.
example.
public setId(String id) throws Exception {
if (id == null) throw new Exception("Err...");
this.id = id;
}
If not how validations done???. :roll:
rgds,
Sudheera
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
It certainly depends on what you want to validate and why, and what the Value Object is used for. So, tell us more, please!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Sudheera Liyanage
Greenhorn

Joined: Oct 14, 2002
Posts: 7
Hi Ilja,
0). This is not for EJB
1). It is a typical CUSTOMER object to be used in various application
2). Implementaion can be change depending on the applications
3). Customer id, name cannot be null for all applications
4). Some other fields cannot be null depending on the application.
I am using,
CustomerDA to access data, CustomerVO to hold data,
CustomerFactory to get CustomerDA implementation and
CustomerBD to encapsulate all of above.
Ex. Application Developers are using following code to load a customer.
CustomerVO custVO = new CustomerVO();
CustomerBD custBD = new CustomerBD();

custBD.load(custVO);
Ilja, am I using design patterns incorrectly ???.
[ February 02, 2004: Message edited by: Sudheera Liyanage ]
[ February 03, 2004: Message edited by: Sudheera Liyanage ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
To be honest, I am not sure. (What does BD stand for, again?)
If I understand correctly, you are getting data from the database, and some values must not be null. How should the system react if they *are* null, nevertheless? How would that happen, anyway?
Joe Nguyen
Ranch Hand

Joined: Apr 20, 2001
Posts: 161
Value Object mainly intends to reduce overhead when accessing data between tiers. Adding business logic, validation rules, to it, may lightly tampers its intend, not to mention that an invoker should set try/catch block when seting value to a value object. I would recommend to have a separate validation routine to validate the data.
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
It might even be a good idea to ensure the fields in the database are set to NOT NULL. Of course this may require resetting any existing null data for those fields to dummy values, but that's a simple update query.
If you can't change the database schema, avoid using logic in the Value Object (I prefer to call them DTO) and use a helper class.
eg.
class MyDTOValidator implements Validator;
if (!MyDTOValidator.validate(MyDTO))
// throw exception from business object.
Sudheera Liyanage
Greenhorn

Joined: Oct 14, 2002
Posts: 7
Joey, Louis thanks for yours replies.
Ilja,
BD means Business Delegate. I use this class to encapsulate
data access mechanism.
BD class will instantiate the Data Access(DA) Object and
delegate create,update,delete operations to DA.
I am not sure whether patterns (ValueObject, BusinessDelegate)
are used correctly.
B Hayes
Ranch Hand

Joined: Feb 07, 2003
Posts: 61
For complex Transfer Objects, would it make sense to use a Helper class as well as a Validator class?
I'm currently designing a TO that will definitely need to be validated before its written by my DAO. But the formatting of some strings is quite finicky.
I was thinking that instead of having the client need to study the specs for the TO (and/or the Validator routines), it might be better to have them deal with a class that helps build the TO properly.
Is this a common pattern?
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
Is this a common pattern?[/QB]

Hi R Hayes,
yes this sounds like a job for strategy pattern. See online docs for more details, but what it allows you to do is implement an on-the-fly algorithm - ie you know the steps required (as determined via methods in an abstract class) - but you dont know how to do them until runtime. So you could easily have a helper type validating each kind of DTO you have.
eg:
abstract interface MyAbstractHelper {
abstract boolean step1();
abstract boolean step2();
}
public class MyFirstValidatorHelper implements MyAbstractHelper{
// implement specific valdidation logic
}
public class MySecondValidatorHelper implements MyAbstractHelper{
// implement specific valdidation logic
}
from your business tier (could be an EJB):
...
private MyAbstractHelper myHelper;
// the type of helper you pass in here determines the kind of
// processing you need:
public void setHelper(MyAbstractHelper helper) {
this.myHelper = helper;
}
// these will probably be called from within business methods:
this.myHelper.step1();
this.myHelper.step1();
This kind of helper strategy can be used across your application, as each DTO will require individual validation. I hope this makes sense.
B Hayes
Ranch Hand

Joined: Feb 07, 2003
Posts: 61
Thanks for posting... after reading the strategy pattern, it seems similar to the factory pattern. Any comments?
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91
Yes, they have similarities, but a factory is more of a wrapper that you call in order to instantiate and return an instance of a class (that extends or implements a common class) of any type, using reflection or classes known at runtime.
The strategy pattern goes a little further by using related classes that implement a workflow differently (can also use reflection). Although they appear similar, the strategy pattern tries to solve a particular problem - ie implement workflow depending on runtime information - whereas factory is a utility for creating objects that may be acting in different scenarios. In fact you could use a factory to instantiate the objects for your strategy pattern.
This is the way I see things.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I was just in another thread about polymorphic behavior for data-only objects, and it came to about the same conclusion. I have a mission to make a stable core with plug-in product lines. My thought was to make a strategy factory, initialized from a configuration file, that gets the right behavior for a given data-only object.

Now I can introduce new data-only classes and new strategies without touching the core code. I think the factory signature will be a bit more complex than that, maybe

I can have a strategy for customer search and another for product search using the very same data-only object. I haven't decided if that's a good thing.
I think I'll also need a String,String method when the caller has the product name but not a product-specific data-only object. Time will tell.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by R Hayes:
Thanks for posting... after reading the strategy pattern, it seems similar to the factory pattern. Any comments?

If you are speaking of Abstract Factory, yes, that's correct. Strategy is a very basic pattern, which you will find reused in many of the others.
Abstract Factory basically is a Strategy for object creation. (As Factory Method is similar to Template Method.)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Stan, you could think of cloning a Prototype in your getStrategy method instead of using reflection to get an instance.
Ben Dover
Ranch Hand

Joined: Jan 30, 2004
Posts: 91

Hi Stan,
Try reading your strategy class name from a properties file, where a String determnined at runtime is mapped to the class name:

This is very powerful as you can change implementations of your strategy without changing your business logic simply by changing the properties file.

I can have a strategy for customer search and another for product search using the very same data-only object. I haven't decided if that's a good thing.

Sure, so long as your logic "knows" what "kind" of search is needed, as likely they will have different logic. No need to pass your value object into the strategy factory if using the properties lookup as above, once you have the strategy object then process:
Strategy myStrategy = StrategyFactory.getStrategyFor(strprop);
myStrategy.process(aParm);
[ February 10, 2004: Message edited by: Louis Saha ]
B Hayes
Ranch Hand

Joined: Feb 07, 2003
Posts: 61
I thought I'd just follow up (to this very informative thread) and say that after looking at a few patterns, I opted on a Builder to create my DTO. I don't know if this is the perfect solution, but,
I looked at the DTO Assembler pattern and the suggested Helper/Validator-Strategy pattern, but the Builder pattern seemed to be a better fit... because there is a "conversion" type of business logic needed to create the DTO, and -- if anything -- the Helper/Validator classes would have helped the Builder, not the client so much.
I now have a class which grabs a DTO from an Oracle DAO and sticks it into a Builder which then spits out (ie: converts) the data into a different DTO for an ASCII file DAO. The yukky business logic for the conversion sits in the Builder.
What do you guys think about that?
--Forgot to add... the DAO sources and business logic will likely change in the future, so additional Builders could easily be made...
[ February 11, 2004: Message edited by: R Hayes ]
 
Don't get me started about those stupid light bulbs.
 
subject: ValueObject pattern question