views:

83

answers:

4

Hello,

I'm interested about using 2 different classes in 2 different environment. Both classes should share the same structure (methods), but the one used in production would be "light", with less verifications or less funtionnality or different actions.

Example: a SQL query class which doesn't check the type/existence of fields. Other example: a error handling class who logs and doesn't display messages.

I presume a specific design pattern already exists, but I don't really know which one I should digg into. Can someone give me a hint here please?

Thanks in advance for the anwser!

+4  A: 

This may just be me...but that's a really bad idea.

You shouldn't have code running in live that you're not running in Development/Test. Otherwise, there's no way to verify that the code is working properly (other than, of course, pushing it in to production and crossing your fingers).

For that reason, I don't think you're going to find a good example of what you're looking for.

Update

What you described is slightly different than how your original question reads. If that's the case, you can have your 'framework' read for a configuration file that specifies validation and logging levels. That way, your configuration file can differ between environments and still be running the same code base.

Justin Niessner
I think he's looking at the flipside of what you describe, code that runs in dev/stage but not production. Regardless +1 because it's still a bad idea.
Chris Lively
Reality is: the code runs first in an development environment, which performs every necessary verification.Then the code is pushed into production. The same code. Just that the underlying layer is lighter and doesn't log as much thing and doesn't check as much thing as in the development part.Like a "framework" thing, with 2 "configurations". It doesn't appear wrong to me. The PHP configuration file (php.ini) isn't the same either when developing / on production.
Savageman
@Savageman - That case is a little different than your original question would sound. See my updated answer.
Justin Niessner
I answered by commenting JuanZe's answer.
Savageman
+1 for moving differences to configuration instead of hard coded into the classes.
chelmertz
Ok, doesn't seem that bad, I'll do this way!Thanks everyone! ;)
Savageman
A: 

Is not a good idea to have different code in your different environments.

For your scenario, I think the best option is to externalize as configuration aspects the things you want to avoid in a particular environment and when the application is deployed set detailed logs on/off, sanity check of fields on/off, etc.

Any changes to the environments must be done in a consistent manner to avoid problems. A version control system and a consistent build and deploy process are your friends for that.

JuanZe
Yes, I see your point. I wouldn't set off sanity checking. Dear Lord! That's not an optional feature.The point is to run 2 versions of the same codebase (which performs the same compulsory actions), and leave off the rest while in production. That said, it's interesting to be able to check everything in production too, but for that I just need to use the other class.My whole preoccupation is about loading less code and performs less check, have a small code that can be read and understand very quickly. Verifications against some configuration just re-add more complexity to the whole thing.
Savageman
A: 

Agreed with most of the comments above with respect to not running different code in production vs. development environments.

That said, you're probably looking for a Factory or Factory Method pattern.

Rob Pelletier
A: 

In my case I have a payment gateway with a sandbox and live environment. what I did was to use a factory pattern + Interfaces (so all gateways have the same signature) + configuration (where the system knows what class need to instance)

Gabriel Sosa