• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Customizing code across clients

 
Ranch Hand
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 3063
12
Mac IntelliJ IDE Python VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Samuel Cox
Ranch Hand
Posts: 96
Scala VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic