I've been charged with re-developing a pretty large retail site and I would like to do it using best OO practices. I am, however, having a little difficulty.
We have products - let's say CD, DVD, Game -, now most of these products are supplied by the company - let's say owodc (cunningly desguised) -, but we have one case where they're supplied by a third party - let's say abcorp - and stored in a seperate database. How to represent this is where the difficulty arrises. I don't want to create seperate classes for each combination (owodcCD, abcorpCD etc.) but at the same time I can't just use a factory method because they differ in more than just object creation (retrieval from the database), they also have unique ways of being inserted into the database and being updated in the database. I was looking at the Strategy pattern and thought it might work but I couldn't figure out how.
Any ideas would be helpfull.
If you need some more info or if I've explained anything badly please let me know.
Cheers
RobHave a main class with all the functions needed by both, then have a class extend that class with the unique functions
class A {
function testA () {
return 'A';
}
}
class B extends A{
function testB () {
return 'B';
}
}
$B = new B;
$B->textA; //Returns 'A';All Strategy really does is isolate repeated parts of code (for example big if/else blocks) and puts each logical decision into it's own class, so the correct one can be chosen and 'plugged in' to the class it was taken from. So in your case you might write DbStorageStrategy classes which could be plugged into your database layer - each one knowing about a specific process of storing a type of CD, a game etc.
I'm not really sure if this is the right solution, I am guessing that a cdwo...I mean owodc CD object spans across different database columns to a company b CD. Could you elaborate on how they differ?
I recommend that you post this question in the PHP Application Design forum on Sitepoint. Not to put this forum down at all, but talk about design patterns which goes on over there is much greater than here.Well, we have one main table in the owodc table, let's call it "products" this has an entry for every product. Then, in the same database, we have cd_products, dvd_products, game_products etc. We also have quite a complicated pricing system and charts etc. In a seperate database ("ext_prods") we have abCorpCD, abCorpDVD and abCorpGame tables which hold the product details for the abCorp products. The owodc and abCorp products differ almost completely. Different locations and schemes for the product details, pricing mechanism etc.
I was thinking about somthing like what you suggest with the storage layer but it would have to be a little more I think, to incorperate caching and the different pricing schemes. What do you think of something like this?
abstract class ProductFactory {
public static function get( $type, $id ) {
switch {
case Product::CDWCD: return CD::get( $id, new CDWCDPersist() );
case Product::CDWDVD: return DVD::get( $id, new CDWDVDPersist() );
case Product::CDWGAME: return GAME::get( $id, new CDWGAMEPersist() );
case Product::EUKCD: return CD::get( $id, new EUKCDPersist() );
case Product::EUKDVD: return DVD::get( $id, new EUKDVDPersist() );
case Product::EUKGAME: return GAME::get( $id, new EUKGAMEPersist() );
}
}
}
abstract class Product {
const
CDWCD = 1,
CDWDVD = 2,
CDWGAME = 3,
CDWELEC = 4,
CDWCOSM = 5,
CDWJWLY = 6,
CDWLING = 7,
EUKCD = 10,
EUKDVD = 11,
EUKGAME = 12;
abstract public static function get( $id, ProductPersist $persist );
}
interface ProductPersist {
public static function getProduct( $id );
public static function updateProduct( $params );
}
/**
* This is just done as a stub, in the real world this has stuff in it's methods
*/
class Persist {
public static function get( $cache_key, $classname, $sql, $sql_vars );
// ...
}
class CDWCDPersist extends Persist implements ProductPersist {
public static function getProduct( $id ) {
$sql = "SQL TO GET THE CDWCD PRODUCT OUT OF THE DATABASE";
$var = array( $id );
return self::get( "product:" . Product::CDWCD . ":" . $id, 'CD', $sql, $var );
}
}
Although, the fact that the two different product "classes" (in the broader sense of the word) differ in so many ways is drawing me towards having two almost totally independent branches of the class hierachy. ie.
- = inherits
: = implements
Product
-CDWProduct
--CDWCDProduct : CD
--CDWDVDProduct : DVD
--CDWGAMEProduct : GAME
-EUKProduct
--EUKCDProduct : CD
...
ProductType
-CD
-DVD
-GAME
We have products - let's say CD, DVD, Game -, now most of these products are supplied by the company - let's say owodc (cunningly desguised) -, but we have one case where they're supplied by a third party - let's say abcorp - and stored in a seperate database. How to represent this is where the difficulty arrises. I don't want to create seperate classes for each combination (owodcCD, abcorpCD etc.) but at the same time I can't just use a factory method because they differ in more than just object creation (retrieval from the database), they also have unique ways of being inserted into the database and being updated in the database. I was looking at the Strategy pattern and thought it might work but I couldn't figure out how.
Any ideas would be helpfull.
If you need some more info or if I've explained anything badly please let me know.
Cheers
RobHave a main class with all the functions needed by both, then have a class extend that class with the unique functions
class A {
function testA () {
return 'A';
}
}
class B extends A{
function testB () {
return 'B';
}
}
$B = new B;
$B->textA; //Returns 'A';All Strategy really does is isolate repeated parts of code (for example big if/else blocks) and puts each logical decision into it's own class, so the correct one can be chosen and 'plugged in' to the class it was taken from. So in your case you might write DbStorageStrategy classes which could be plugged into your database layer - each one knowing about a specific process of storing a type of CD, a game etc.
I'm not really sure if this is the right solution, I am guessing that a cdwo...I mean owodc CD object spans across different database columns to a company b CD. Could you elaborate on how they differ?
I recommend that you post this question in the PHP Application Design forum on Sitepoint. Not to put this forum down at all, but talk about design patterns which goes on over there is much greater than here.Well, we have one main table in the owodc table, let's call it "products" this has an entry for every product. Then, in the same database, we have cd_products, dvd_products, game_products etc. We also have quite a complicated pricing system and charts etc. In a seperate database ("ext_prods") we have abCorpCD, abCorpDVD and abCorpGame tables which hold the product details for the abCorp products. The owodc and abCorp products differ almost completely. Different locations and schemes for the product details, pricing mechanism etc.
I was thinking about somthing like what you suggest with the storage layer but it would have to be a little more I think, to incorperate caching and the different pricing schemes. What do you think of something like this?
abstract class ProductFactory {
public static function get( $type, $id ) {
switch {
case Product::CDWCD: return CD::get( $id, new CDWCDPersist() );
case Product::CDWDVD: return DVD::get( $id, new CDWDVDPersist() );
case Product::CDWGAME: return GAME::get( $id, new CDWGAMEPersist() );
case Product::EUKCD: return CD::get( $id, new EUKCDPersist() );
case Product::EUKDVD: return DVD::get( $id, new EUKDVDPersist() );
case Product::EUKGAME: return GAME::get( $id, new EUKGAMEPersist() );
}
}
}
abstract class Product {
const
CDWCD = 1,
CDWDVD = 2,
CDWGAME = 3,
CDWELEC = 4,
CDWCOSM = 5,
CDWJWLY = 6,
CDWLING = 7,
EUKCD = 10,
EUKDVD = 11,
EUKGAME = 12;
abstract public static function get( $id, ProductPersist $persist );
}
interface ProductPersist {
public static function getProduct( $id );
public static function updateProduct( $params );
}
/**
* This is just done as a stub, in the real world this has stuff in it's methods
*/
class Persist {
public static function get( $cache_key, $classname, $sql, $sql_vars );
// ...
}
class CDWCDPersist extends Persist implements ProductPersist {
public static function getProduct( $id ) {
$sql = "SQL TO GET THE CDWCD PRODUCT OUT OF THE DATABASE";
$var = array( $id );
return self::get( "product:" . Product::CDWCD . ":" . $id, 'CD', $sql, $var );
}
}
Although, the fact that the two different product "classes" (in the broader sense of the word) differ in so many ways is drawing me towards having two almost totally independent branches of the class hierachy. ie.
- = inherits
: = implements
Product
-CDWProduct
--CDWCDProduct : CD
--CDWDVDProduct : DVD
--CDWGAMEProduct : GAME
-EUKProduct
--EUKCDProduct : CD
...
ProductType
-CD
-DVD
-GAME