Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Customizing code across clients

 
Samuel Cox
Ranch Hand
Posts: 96
Scala Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • 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.
 
Greg Charles
Sheriff
Posts: 2985
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • 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.
 
Kerry Friesen
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • 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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • 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 Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • 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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • 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 ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic