Encapsulating business logic thru a common class?
Let's consider this situation here:
Because of business functionality A, I need to contact DB table:DB1
For functionality B, I need to contact DB table:DB2
Tomorrow, I may have func. C, for which I might need DB table:DB3
What I want is for a central class (CClass) I call another class (GClass)through a generic method of GClass. It will this method's implementation which will decide on the functionality (a switch case maybe?) and call the appropriate business entity performing this task.
What will be the best way to achieve this?
An example I have:
publicclass CallTheServer{
ServerFacade sf =new ServerFacade();
BalanceServerEntResponse bser = sf.getData(My_Data_Object) ;
// ..
}
publicclass ServerFacade{
public Object getData(objToDetermine Object){
if (objToDetermine instanceOf BalanceServer){
BalanceServer bs =new BalanceServer() ;
BalanceServerEntResponse bser = bs.processData(objToDetermine);
return (Object)bser ;
}
}
/* The BalanceServer/BalanceServerEntResponse classes here is a protected class within package:balance which contain ServerFacade with appro. methods. */
What you see here is this package:balance will be called by various other classes. However all such classes will call the same method of the Facade class. Inside Facade class method, based on the type of object passed, the associated entity is being invoked. Of course the caller program knows the object:My_Data_Object here.
Don't know if this a correct approach. I am sure there is more elegant way of doing this. Please help.
[2213 byte] By [
baivaba] at [2007-9-28 18:40:14]
Oops .. forgot to downcast/upcast in the code. Also, there seems to be
something called Visitor pattern which can be used here.
The cause of the Visitor pattern is due to this problem: (it seems)
>>>A transaction object is provided to the client and... the client must now select the right UI classes and pass the newly created
transaction class to it. This is a relatively simple process of
checking the class type information and using a switch or if statement
to select the right UI class but I'm almost positive there is a better
way. The second problem arises from the fact that the base class
reference must be down cast (i.e. cast to a subclass) to allow access
to the subclass attributes and behaviour which seems inelegant at best.
instanceof is often bad design. Most of the time, you can use poymorphism instead, which is much better regarding to 00 design.
As a first idea, I would had a method "getData" for each type of data you might need.
For instance, if you process, say, a BalanceServer and an AccountServer, add :
getData(BalanceServer)
getData(AccountServer).
If the only difference between the differtent funcionalities is the DB to contact - as you write in your first message - you can do even better. Create an Hashtable (or Hashmap) with classes as keys and Table names as values. You can initiliaze it using a configuration file or reading a DB. With this solution, you'll just have call a generic code that does the job, regardless of the type of object. When you'll create your func C, you won't have to change your code - you'll just have to change the configuration.
Is this answer of any help?
/Stephane.
