Architecture: using different classes on development / production

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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)

Answer 4

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.