Efficiently Using Hardcoded Variables in OO PHP

PHP
1

SOS: I’m at a loss.

I want to create a new object without knowing the class when I first go to create it. That points me towards a factory pattern; I want my controller to capture and sanitize user input, then send it to a factory to create a new object.

Based on part of the user input - specifically, a “type” value that will be chosen from a list of predefined types - I want my new object (model) to have a set of specific hardcoded variables (properties). These properties include things such as a template URL (which provides a template to format data for output (basically a view)) and a list of table names I need to gather data from.

An object of Type A might want to access tables(“t_x”, “t_y”, “t_z”) and send the data to a template at “template_a.php”.

An object of Type B might want to instead access tables(“t_c”, “t_d”) and send the data to a template at “template_b.php”.

While I’m sure I could do something fancy to generate the template URLs based on the type (as long as they follow a specific naming convention), things like the table set cannot be generated automatically. I am not sure where in my application this hardcoded information needs to live / reside.

Am I on the right track using a factory pattern, where the factory would specify which class to instantiate (and the class would tell the new object to contain my hard-coded variables)?

Should I use if-else statements (ew) or switches (potentially a valid option since there will only be a handful of types to choose from)? I am new to OOP and feel a little lost, but I really dont want to leave a mess for the next guy (who might be future-me).

All guidance is appreciated. Please let me know if further clarification is needed.

Edit: I’m hoping I’ve found the right solution.

I think I can get the code to function as desired by using factories. I will have a general class to define which variables are needed, and then have a separate extension of that class for each different type. The sub-classes will define the variables in the __construct() function, so each new object will have the right values for its type.

2

Hi tputman,
Just a thought here, and I hope I’m understanding your problem:
If you are using a factory to instantiate different objects there must be something in common between those objects so why not then use a common interface and have those object classes extend it. Then those specific object classes could have those values you are after defined as properties… would this work? not 100% sure in your case but hope it helps.

Andres

<?php

class MyInterface 
{	
    protected $template = '/path/to/my/default/template.tpl';

    protected function render() 
    {
        $templateVariables = [];
        $content = SomeUtilityHTMLClass::template($this->template, $templateVariables);
        return $content;
    }
}

class MyClassA extends MyInterface 
{
	protected $template = '/path/to/templateA.tpl';	
}

class MyClassB extends MyInterface 
{    
    protected $template = '/path/to/templateB.tpl';	
}
3

It doesn’t sound like A and B have anything in common, so a factory is not the way to go here.

I would detect early in the controller which variant you’re dealing with and then call a private method in the controller for exactly that case. So one if and two private methods.

If you’re doing this in a framework that supports subrequests (like Symfony) that would also work and be a bit cleaner.

4

Thanks for taking the time to answer!

A and B have a couple of things in common (that I should’ve stated above):

They each have other attributes (like the database name) that will not change. They also each use the same methods to open, use, and close a database connection.

The variables that will not change between types, as well as the methods to access the database, are specified in my superclass. All of the individual types are extensions of that superclass, and exist only to specify the variables that change between each type.

This setup (theoretically) allows me to call what I need, based on the type, and still reuse my code for the properties and methods that do not change.

5

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.