Is there a pattern to describe a class that symbolises an instance of an instance of another class?

Question

I am currently working on a project that generates videos from templates (a template being a collection of JSON files and assets).

It seems natural to have a Template class that contains all the info of how this specific template is structured (e.g. which parts are personaliseable, what assets are required etc...).

The issue I have been hung up on is how to model a job. A job takes a particular Template, allows assigning values to the personaliseable fields and renders a video using these values. To me, it makes sense that a Job would be an instance of an instance of Template.

A solution I am imagining is something like this (in pseudo-Typescript):

class Template {
    // elements in groups can be subclasses of the generic TemplateField - I'd like to preserve that and their grouping in the DynamicallyCreatedTemplateClass that is generated below
    templateFields : Group<TemplateField>[];

    constructor( sourcePath : string) {
        // build shape of templateFields from a file
    }

    // This should return a constructor for a dynamically created class that inherits from Template as well as a Job mixin but already has a concrete structure in this.templateFields
    // in general, the resulting class should resemble the Template instance this is called on (i.e. properties that have values on the instance should have the same values in every instance of the generated class)
    getInstanceClass() : () => DynamicallyCreatedTemplateClass { /* ??? */ }
}

const someTemplate = new Template('/path/to/some/file.json');

const someJob = new someTemplate.getInstanceClass();

someJob.templateFields[0].get(0).value = 'something';
if(
    someJob.templateFields[0].get(0).type == someTemplate.templateFields[0].get(0).type &&
    typeof someTemplate.templateFields[0].get(0).value === 'undefined'
)
        console.log('success!');

Is there a pattern to describe this relationship or am I going about this all wrong?

Answer 1

The question is, what do you want to achieve by using this design. If what you're intending to do makes sense may also depend on it being the common way of achieving this in the language of your choice.

To me your explanation sounds to me like your Job inherits from your Template.

Your code looks like your Template is a Job factory.

The latter makes more sense to me. The purpose of inheritance is to achieve runtime polymorphism. A template is not a job and vice versa.

Making your Template a Job factory makes perfect sense. What I would recommend is that your Job takes a template reference in its constructor to create an aggregation (this is also called dependency injection).

In C++ I would declare friend class Template and make Job's constructor private so only your Job factory (aka. the Template class) can create jobs.

In Java I would make Job's constructor protected and stick them into a common namespace.

Answer 2

From what I see here, it would make sense, to have the following components:

• Template - Holds necessary information for render. Restricts modification of some of its parts. Renders itself

• Template Builder - which configures the template with the necessary information.

The modeled flow would be something like this:

template = new TemplateBuilder(config).build();
template.render()

No "job" required.

Your "template" is something like a factory and your job does some configuration and carries out the "rendering", which from my point of view it shouldn't - because it is not its responsibility.

Answer 3

Alright, here's my thoughts after hearing your suggestions:

First of all, a Template really should only be a data class that reads a config file and then exists in that state without doing much.

There are two ways a Template can be interacted with:

1) its configuration can be changed (i.e. TemplateFields added/removed, assets changed, previews generated etc...)

2) its fields can be filled with values and it can be rendered

I used to have the first one blended in with the Template data and the second one was modelled as a Job.

So, taking that into account, I came up with this:

// this is a necessity for mixins in TypeScript
type Constructor<T> = new(...args: any[]) => T;

// the "pure data" template class
class Template {
    templateFieldGroups : TemplateFieldGroup[];
    // other properties

    constructor() {
        // load from disk
    }
}

// The mixin to add Job-specific functionality (saving TemplateField values and rendering)
function JobMixin<T extends Constructor<Template>>(Base : T) {
    return class extends Base {
        constructor(...args: any[]) {
            super(...args);
        }

        render(){}
        saveValuesToDB(){}
        loadValuesFromDB(){}
    }
}

// The mixin to add management functionality
function TemplateManagerMixin<T extends Constructor<Template>>(Base : T) {
    return class extends Base {
        constructor(...args: any[]) {
            super(...args);
        }

        createPreviews(){}
    }
}

// The class that will be used to configure the templates
class TemplateManager extends TemplateManagerMixin(Template) {
}

// The class that will be used to handle specific template instances and render them
class Job extends JobMixin(Template) {
}

I don't know if this is really the very best way to do it, but it does appear to be fairly intuitive from a usability perspective to me.

Thank you again to kamikaze and Thomas Junk for your input.