This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes Java in General and the fly likes Customizing code across clients Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Customizing code across clients" Watch "Customizing code across clients" New topic
Author

Customizing code across clients

Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Hi,

In several areas of my generic application, I need to assess fees associated with a given object. The algorithm governing how these fees apply to the object vary depending on the company who has bought my software. I thought that I would create an FeeAssessor interface with an applyFees() method that would be defined by the various algorithms. However, I quickly realized that my generic application would need to instantiate the customized objects based on who was using the software. Therefore, I'd have a big if-elseif-elseif construct, which is what I was trying to avoid with the interface. Obviously, I have misapplied the purpose of an interface or have some other misunderstanding.

Does anyone have any suggestions or suggested readings on how to approach this problem? It is a Struts web application if that helps at all, but this should be pure business logic so I thought this was a better forum.
Greg Charles
Sheriff

Joined: Oct 01, 2001
Posts: 2774
    
  10

Well, you have to identify the client in some way. You could have a property or something like that. You could then deliver to each client a custom fee computation class with a name like that property, and use reflection to instantiate it. I think a factory class might be useful to do that work for you.
Kerry Friesen
Greenhorn

Joined: Oct 10, 2003
Posts: 23
Originally posted by Samuel Cox:
Hi,

In several areas of my generic application, I need to assess fees associated with a given object. The algorithm governing how these fees apply to the object vary depending on the company who has bought my software. I thought that I would create an FeeAssessor interface with an applyFees() method that would be defined by the various algorithms. However, I quickly realized that my generic application would need to instantiate the customized objects based on who was using the software. Therefore, I'd have a big if-elseif-elseif construct, which is what I was trying to avoid with the interface. Obviously, I have misapplied the purpose of an interface or have some other misunderstanding.

Does anyone have any suggestions or suggested readings on how to approach this problem? It is a Struts web application if that helps at all, but this should be pure business logic so I thought this was a better forum.


Hi Samuel,

Continuting where Greg's post left off, I agree with him and think your situation would warrant the use of the factory pattern. It appears that you need to create objects differently (based on customer), but once they are created you use them in the same manner (apply fees). The following link should give you some additional insight on the factory pattern:

java.net - Factory Pattern

Cheers,
Kerry


Kerry Friesen<br />SCJP 1.2<br />SCJD
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Or you could simply provide the fully qualified class name by some configuration mechanism (property file or something) and instanciate it via reflection:



That way, you don't have to change any code when you need to inject a new implementation.

Google for "Dependency Injection" for variations of this pattern.


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
Samuel Cox
Ranch Hand

Joined: Nov 16, 2004
Posts: 96

Thanks for all the suggestions.

They both seem relatively straightforward.

Would you say that one way or the other is a more accepted method for 'injecting' custom code into your generic solution?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
For more ideas, read up on Dependency Injection. In this paper Fowler gives several ways to configure options like this ... setters, constructors, etc.

You already have a good grip on Dependency Inversion ... your core modules define the interfaces and customer plug ins implement them.

I borrowed an "Application Assembler" concept from Fowler's paper, though I'm not sure how close it is to his description any more. It reads configuration and "pushes" settings to objects that need them. It's very easy for unit tests to set mock configurations, and avoids dependencies from the core module on the configuration module. The assembler has lots of:

[ December 06, 2005: Message edited by: Stan James ]

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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Customizing code across clients
 
Similar Threads
Unfortunate new graduates
Looking for some nice advice
Switch case vs If elseif
Presenting a generic interface to access external system in component diagram
Avoiding too many if..elseif...else statements.