Design pattern for creating object hidden from client

Question

I am having difficulty understanding which design pattern would be best for the following scenario. An application uses a database. That database can either be the production version (SQL) or a test version (Test). Here's my current design:

The problem with this design is that application has to create Test, which it shouldn't be doing (since it's purely for testing). However, Application must somehow get reference to the database it's going to use, either SQL or Test.

What design pattern could I implement to fool application into creating the Test version of the database? How would this solution look in UML?

I have already done enough research to narrow my choices to Abstract Factory, Builder, or Factory Method (or the combination of any)

Answer 1

When you want a part of your program to instantiate a certain subclass, but hide the instantiation behavior from other client code (your Application class), you should probably go with the Factory Method DP.

That relates to the instantiation part. Regarding the actual behavioral differences between the subclasses, the Strategy DP may be a good solution, as stated by @Paul.

Answer 2

Before I get to the gist of your question, let me point out that the structure you provided has certain problems (which you have noticed, but let me elaborate a bit):

This design uses dependency inversion to make the client (Application) and a concrete service (a DB gateway - SQL, Test) independent of each other, by making each depend on the IDatabase interface. However, the fact that Application creates the concrete service makes it dependent on the concrete type, which to some extent messes up the whole setup. The degree to which this is actually a problem depends on thinks like: what the client code does, developer discipline (in terms of isolating the coupling to a well defined piece of the Application class), techniques used (e.g. the picture changes a bit if the concrete service is instantiated through reflection), how you want to organize your code into libraries, etc.

Relying just on the traditional OO techniques, the way to make sure that client code has no knowledge of the concrete types that implement IDatabase is to introduce a third piece of code that knows about all of these types, and is therefore able to hook them up (and this, in turn, enables these types to stay decoupled). In approaches that use dependency injection, this third piece of code will usually be the composition root (more or less, the entry point of the application).

One way to change the original class diagram you posted so that it follows this structure is to split the Application class into two parts. One part will be the composition root (the ting that does creating and hooking up, and runs the other part, or otherwise enables it to run). The other part will be the client code that uses IDatabase.

This enables you to test this other part (the actual business logic contained in the client code) in isolation (e.g., unit testing) by supplying a concrete database instance in the test code via constructor injection.

The way I described it so far, when it comes to creating concrete instances, the composition root essentially uses "code as configuration", but if you want to (or need to), you can make it truly configurable by having it read a config file and make its decisions based on that data, or you can rely on a DI container to manage the configuration, dependency injection and object lifecycle for you.

Answer 3

So, the short answer to your question is that the pattern you're trying to find is probably the Strategy Pattern, as you're interested in selecting an implementation at runtime. Especially if the implementation in your code is very different (eg your real DB is an RDBMS but your test DB is just flat files of test data)

But having said that, I think it's a mistake to try and think of your software in terms of what design patterns it needs. For the most part, you should start with the simplest possible approach and refactor to a pattern when your simple approach isn't good enough.

What do I mean?

Well, let's take your case. In the simplest version, I'd argue that all you need to do is change the DB connectionstring based on environment (prod or test). So, put the connection info in an environment variable and be done with it.

If you find that you need more changes, let's say you need different seed data. Then, either add a function to your test that runs before the test logic to update the content or maybe here you have a seed data file that you select based on another env var.

If you need yet more differences, there's a good chance your design is bad because why would you spend so much time test stuff that's different than what you're doing in production?

Ok, I tricked you. There's actually very little reason to ever use the Strategy Pattern to solve this problem. But it is the one you were "looking for" with how you asked the question. See what I mean?

Answer 4

In your design, the application creates its database. However, the application does not have the necessary information to choose the database. Instead, pass a database to the application.

For example, in your application startup code:

Database db = new MySQLConnection(...);
Application app = new Application(db);
app.run();

But in your test code:

Database db = new TestDBConnection(...);
Application app = new Application(db);
app.run();

That is, we inject the dependency into the application, using the Database interface.

Instead of manually injecting dependencies through constructor arguments or function arguments, you could also use a dependency injection framework. Then, the application would request a Database object from the DI framework, and we would have previously configured the DI framework to use a specific class to implement the Database interface. However, use of a framework is not required, and constructor injection works just fine for most projects.

Answer 5

Here's the UML to complement the other answers:

Factory

There are at least three variants of the Factory pattern, e.g., Static, Concrete, Factory Method, and Abstract Factory. Static won't really work with an Interface, so Concrete would be adequate if all you want to do is not have Application know about creation details. Factory Method and Abstract Factory don't seem to be appropriate for the situation you've given in the question.

When Application uses a Factory, Application still decides which Database is instantiated, even if the details of how the database is instantiated are hidden in the Factory.

Dependency Injection

Application does not decide which Database is instantiated; some other class, e.g., Decider, does. Decider may use a factory to insulate it from the instantiation details (as above).