Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Working on a major enhancement for legacy code, I have been wrestling with myself over whether this is a good case to use the Proxy pattern, and more specifically whether a good case to use the Java Dynamic Proxy API.

BACKGROUND We have a "FIXConnection" class used to send orders to a destination. The application maintains 1 to n FIXConnections for sending (a specific object is selected based on what the user specified on the order).

Normally, the order would be sent straight out to the market. The enhancement is to see whether order could be filled by other orders already sent to market before sending, and if it can be filled, execute totally different logic (i.e. not send). If not, it delegates to current logic.

This feature will only be used by one client, so it is turned on/off dynamically (or by configuration setting).

It feels like this is a good use for the Proxy pattern/Dynamic Proxy, because it would allow designing a block of code to intercept requests to the existing FIXConnection.send method (and also its processResponse method), only in the case whether the feature is enabled. The Proxy could either execute the new logic (if warranted), or dispatch to existing logic.


  • Using Proxy avoids any issues with Class hierarchy (we occasionally subclass this FIXConnection class). If we handled this by subclass, then other children might need to be moved to this under this as a parent.

  • We don't need to update the existing top level class with any flag to check if this feature is enabled, and to conditionally execute code. (i.e. not create code for one special case, which would now be hit by all cases).

  • Single point of control


  • Existing class exposes public variables, all would need to be refactored into getter/setter methods, and need to extract an interface (so that Dynamic Proxy could be used). i.e. a ripple throughout other classes.

  • Binding between the proxy and legacy method could be a little cheesy (e.g. method.getName().equals("send"). There are ways of more tightly binding, but ... (yuck?)

  • Is this making things unnecessarily complicated? In general I try to subscribe to doing "the simplest thing that could work". This doesn't quite feel like it.

Would love to hear anyone's thoughts about how they might handle this design question.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

The big thing here is what are the chances you'll need to do this for other clients? If the odds of any other client using this are low to nil, refactoring may be a lot of time and effort for something with very minor impact. However, if you think this could be an enhancement you'll be making for more clients, I would go ahead and make the change to the code.

If you do refactor, I think the Strategy pattern is a better fit for this particular situation. It sounds like you're not so much looking for an object to operate in place of another object so much as you're looking to alter the server's behavior based on the specific situation. Clients (I'm assuming at this point that ultimately this will be used by more than 1 client) that would use this enhancement would use a strategy that checks existing orders before sending out a new order, other clients would use a strategy that always sends orders to market. As clients start to use this feature, they use the appropriate strategy with minimal changes on your part.

share|improve this answer
OK - I'm thinking about this suggestion. This would require some minor change to the client code, to call the Strategy execute method, instead of calling the send method directly (which is what it does now). (Essentially the Strategy is now the Proxy for accessing the send method.) However, I'll also need to similarly insert a Strategy method call on the processResponse side as well. The benefit of this suggestion is that it eliminates the cheesy binding between the proxy and the implementing class. –  Sam Goldberg Jul 5 '11 at 19:26
add comment

I think that most of the cons you face are result of bad design choice that preceed your work.

Not refactoring is the solution that increase technocal debt. It's sometime OK, for exemple when you have to meet a close deadline, but it cost more than refactoring in the long run. Moreover, the more you'll choose to not refactor, the harder it will be to refactor.

So I would definitvely go for using the pattern and refactoring. You should check that with your project manager anyway, I may know time constraint that you don't. Explain him/her that the work you will do by refactoring will have to be done at some point, or will cost a lot to the company when time comes to add functionnaly or deal with tedious bugs.

You may want to read this : http://schneide.wordpress.com/2011/01/03/a-tale-of-scrap-metal-code-part-i/ to know what happen when you choose the drak side of the code.

share|improve this answer
Run your post through a spell-checker please. –  Robert Harvey Jul 5 '11 at 17:37
ok - edited. Do you have any further comment? –  Sam Goldberg Jul 5 '11 at 17:48
OK, sorry guys. I was at work and my spellchecker was set in french. Sorry for the inconvenience. –  deadalnix Jul 5 '11 at 23:43
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.