We have an Yii-based PHP application which does some generic actions (like "Share" with social networks or "Buy" in internal web shop) on different types of objects.
Right now developers use the class constants to separate objects of different types. Like so:
in model:
class Referral extends CActiveRecord {
//... a lot more stuff here...
const ITEM_TYPE_PRODUCT = 'product';
const ITEM_TYPE_DESIGN = 'design';
const ITEM_TYPE_BRAND = 'brand';
const ITEM_TYPE_INVITE = 'invite';
const ITEM_TYPE_DESIGNER = 'designer';
//... a lot more stuff here...
}
then later in some controller:
// calling static method of Referral and pass a type IDs to change it's behavior
$referral_params = Referral::buildReferallParams(
Referral::TYPE_PINTEREST,
Referral::ITEM_TYPE_PRODUCT
)
This usage of class constants has led to major code duplication which I want to move away.
I personally think we should really add a lookup table for types, like so:
CREATE TABLE `item_type` (
id int primary key auto_increment,
name varchar(255)
);
And make a Yii model class named ItemType to extract IDs from the table with.
But it leads to another problem: we need to use this type IDs in the code anyway and will need to do so for a long time. We need to make a symbolic names for IDs somehow. Right now the call like Referral::ITEM_TYPE_PRODUCT is very convenient, and to change it to Yii-flavored ItemType::model()->findByAttributes(array('name' => 'Product')) is totally unacceptable.
I want to avoid maintaining the same list of class constants (which is duplicated now through our codebase) in the ItemType because each addition of new type will require addition of new constants and it's just a out-of-sync problem waiting to occur.
So, the question is as follows: how to make an ActiveRecord for a lookup table equally useful as the 'enum'-like set of numeric constants?
I came with the following somewhat beautiful solution, using the subclasses of ItemType:
ProductItemType::id(); // returns lazy-loaded ID for 'Product' item type
BrandItemType::id(); // the same for 'Brand' item type
// ... and so on
But if requires five subclasses of single base class right now and maybe another half of dozen more later. Is there any viable architectural solution?
EDIT
Problem with duplication is this: class constants declaring type IDs become redefined in every class which needs to somehow differentiate between different item types. I know that the most "true" solution would be to invert this inside out and move the features which depends on the type of object to the objects itself, but we have legacy code without any test coverage and this solution is just a dream right now. Right now all I want to do is remove this duplication. And constants, too.
