Preparing to Use the Faux Implementation Pattern

In general, how you go about building a faux implementation depends on the situation you find yourself addressing. Keep the following tips in mind:

Use a class factory if you are in a test scenario where you want to load different implementations of test classes: Class factories are good at hiding the details of what implementation class your component uses. Further, this technique is simply good programming when there are points in your code that may receive new implementations to plug in over time.

A FauxImplementation instance does not have to have aRealImplementation counterpart : In the case of the upcoming Web Service example, you rely on the faux implementation for your application and never build an "expected" implementation of your service.

The faux implementation can be fragile: Most likely, your implementation will be much lighter and not as robust as the real implementation. Further, if you misinterpret the specification, your implementation may work for a while until the server component fixes the behavioral specification. At this point, the faux implementation will likely break.

Ensure behavior consistency as well as interface consistency between the real and faux implementations: Nothing is more frustrating than finding a behavior in an emulator that does not represent the real world. Consider the test scenario where you write a test implementation that you use to get your music viewer working. The real implementation team gets around to delivering you the production components and your music viewer blows up because of a behavior change. Whose component is right? The architecture document should settle the argument, but often the architecture document does not contain a description of the behavior in question. If it did, your viewer would have worked because you would have implemented the test implementation according to the specification.