I’d like to build upon the solution @TMN is presenting and take it a little further to answer your SRP problem. Putting database code inside the ProductFactory would be non-sensical so to encapsulate this responsibility you can create a separate class ProductModelNumberProvider with just one method findByProductId(int productId).

The ProductFactory should provide a setter setProductModelNumberProvider(ProductModelNumberProvider lookupProvider) which will assign the provider internally and call findByProductId() when appropriate.

You will have a ProductFactory which is responsible for building the product and a ProductModelNumberProvider which will do the database interaction if needed.

Have a look at your StackOverflow question for a more concrete example.

Maybe create a ProductFactory, with methods to create a Product given a number of wheels and either a product ID or a model number. Given a model number it defers to the class’ constructor, and if given a product ID it performs the DB lookup, gets the model number, then defers to the class constructor.

You don’t want to duplicate the DB mapping product_id -> model_number by hardcoding the logic, that makes sense. So the first thing you need is a function like

int mapProductIdToModelNumber(int product_id)

which does this mapping by getting the information from the database (consider caching when this function is used very often).

What remains is how to make this function available to your Product class without tight coupling. You have the following alternatives:

• pass the function directly to the code blocks whereever Product objects are created (depends on your programming language how to accomplish that)

• implement the function in a ProductFactory class. Derive ProductFactory from an interface IProductFactory and pass an object of this type to the code areas where you currently want a new Product(). Use the factory the way @TMN suggested.

That way, your legacy code stays decoupled from the database, since it won’t depend directly from a database-bound ProductFactory, only from IProductFactory, which can be easily mocked out (for example, for testing purposes).

Maybe this — give up the idea of a Product class and create a DB-wrapper where I will say $pf = ProductFinder(), then do $pf->findById() and $pf->findByModel() as needed. Problem: Where do I put my computation code? It can’t be in the same place, as it it will violate Single Responsibility Principle. aka, computation and data handling should be separate. Then maybe Product class can be the computational part, and ProductFinder be the database pulling part.

What I actually ended up doing:

At first I was wondering if I am better off with such complexity.

Simpler way was:

There is another pattern here that I could use that keeps things in one class: https://stackoverflow.com/a/2175213/2883328. Breaks SRP.

$product = Product::fromProductId($productId, $wheels);

SRP way (chosen)

• ProductData class that just has the data (can be swapped by database later)
• ProductFactory class that uses Provider class to look up the model number
• ProductNumberProvider class that provides model number when given product id
• Product class that does loads ProductData and does computations

Code:

$provider = new ProductModelNumberProvider();
$factory = new ProductFactory($provider);
$product = $factory->constructFromProductId($productId, $wheels);