I was wondering how you'd be able to map the following criterias to common design patterns. I use PHP 5.3 and MySQL 5.5 and have my own mvc framework for my company but some parts could be better and here are the requirements:

(Take the concept of a catalog since it's the first app that would be affected in our application pool)

The controllers (products, clients and basket) all manage different information namely their own set of models. For example, the basket will create basket objects in memory, assign products to it, quantities, etc. Then it will save the basket to database and try the payment logic and save the payment associated to the basket.

My issue is that most of the time, our clients want to customize the different objects such as the client (add more coordinate fields or descriptive fields) or the product (add custom properties to the product). If my controller always refers to the class product but i want to extend it to create:

MyClient_Models_Product extends MyCompany_Models_Product

How will i setup my system to support extension of classes and change the classes used by my different modules, controllers, views and other models. If i hardcode MyCompany_Models_Product as the class name in the controller and all other object, how would i go at creating an overridable system.

Is there any pattern i can go for that will leverage this problem?


2 Answers 2


Don't do this through extension. You already have a sense for what a mess this can turn into. Compile-time extension can -very- easily lead to this kind of class explosion (You don't wanna extend Product once for every combination of extra properties the client needs). Instead, use runtime composition.

A few relevant questions:

Will these changes affect logic, or are they always (or even mostly) only be additional properties? If so, why not create a class called ProductProperty that has Key and Value properties? Create your Products through a factory that can not only instantiate the Product class, but can also check the database to see what additional fields the client has requested be on the Product. You may need to separately store this as metadata somewhere in the database. For every additional field your client has specified as needing, you can instantiate another ProductProperty and store them in some internal list of the Product instance.

You may also want to add some useful methods like Product.hasProperty, .getValue, etc, to make accessing - and maybe even iterating - these properties less of a hassle.

  • Thanks for your comment, actually yes, most of the time, the custom properties will be placed in the custom properties module but a lot of time, we get weird business logic related to the products and instead of placing it in a custom plugin in the controller, we want to extend the model that already contains most of the business logic... Commented Feb 24, 2012 at 13:17
  • Sorry...didn't really notice your followup solution until...now o:) Also I'm not too familiar with C# syntax so I'm not exactly sure what you're expressing w/ the code below.
    – Montagist
    Commented Jun 19, 2012 at 19:03

I thought about it last night before going to sleep and i'd like your input on this solution:

I'd use some kind of factory pattern which i don't know the name of. By default this factory could be called:


And you could call:


And by default it would call:


when i register the module into the system.

Then, calling the getProductModel or getProductFactory, i could extend my whole logic. Obviously i can't extend the controllers or i'd face problems relative to instanciation but all in all, i think thats a good pattern...

Need to know if there is a pattern name for that...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.