0

The general problem I'm trying to solve is one in which the code of a specific method is growing too large since much of the logic is starting to differ greatly between specific users. For instance, in order to determine the best shipping method for Customer X, a lot of different factors and logic are considered than when determining the same thing for Customers A, B, C...

This seems like a good candidate to refactor using the Strategy pattern, but I'm wondering if, since there are many, many clients, each of which may require specific tweaks to their logic, am I better off using a scripting language to encapsulate this logic, rather than needing to create new strategy implementations for as many clients as need custom logic?

ksigmund
  • 527
  • 1
  • 6
  • 13
  • 1
    Using a delegate is also a possibility (if the logic isn't too complicated and doesn't really require storing different state etc. between implementations). Then you get the benefit of using lambda expressions being passed into your GetShippingMethod or whatever. – Jason Down Sep 25 '14 at 18:38
  • In my experience, strategy and delegation aren't necessarily mutually exclusive, but for some instances, I think delegation is indeed the better choice. Thanks! – ksigmund Sep 25 '14 at 18:42
  • Shockingly, this may actually be the sole remaining legitimate use of an abstract factory pattern. Use configuration to xref the names of dlls with users and dynamically pick one in code. Then you don't have to full redeploy each time you add a user and any changes to one user's logic can be partially deployed with xcopy of the dll (assuming this is a web app or web service that can tear-down the app domain with each request). – Keith Payne Sep 25 '14 at 18:44
  • Agreed. Actually I just found a question on SO that discusses the pros and cons vs the two approaches (not the same thing as you are asking so I won't try to mark this as a duplicate): http://stackoverflow.com/questions/984050/c-sharp-strategy-design-pattern-by-delegate-vs-oop – Jason Down Sep 25 '14 at 18:45
  • @KeithPayne: Interesting approach! I like it. – Jason Down Sep 25 '14 at 18:47

1 Answers1

1

I see you are using .Net.

In my experience both are possible, the single problem using scripting is that you have to use reflection and is hard to debug when you have problems in code.

A very easy to work with language is Boo, and is better to use the Compiler API to make sure that at least the user's code compile!

As for me, if you want to validate/test the user code, and you will want to face multiple interactions (that can change), I would use not so much strategy, but something like:

This will avoid cases when the scripting is done wrong and is hard to debug.

Also it makes your software composable and testable and you can add later logging or other critical components if the data introduced by the user becomes invalid.

Ciprian Khlud
  • 434
  • 3
  • 6