Mastering the Builder Pattern: Create a Dynamic AI Prompt Generator CLI

Have you ever encountered a case in your development journey where you had to deal with complex objects? Maybe because they either have too many parameters, which can even be nested, or require many building steps and complex logic to be constructed.

Perhaps you want to design a module with a clean and easy interface without having to scatter or think about the creation code of your complex objects every time!

That's where the builder design pattern comes in!

Throughout this tutorial, we will be explaining everything about the builder design pattern, then we will build a CLI Node.js application for generating a DALL-E 3 optimized image generation prompt using the builder design pattern.

The final code is available in this Github Repository.

Overview

Builder is a creational design pattern, which is a category of design patterns that deals with the different problems that come with the native way of creating objects with the new keyword or operator.

Problem

The Builder Design Pattern focuses on solving the following problems:

1. Providing an easy interface to create complex objects: Imagine a deeply nested object with many required initialization steps.

2. Separating the construction code from the object itself, allowing for the creation of multiple representations or configurations out of the same object.

Solution

The Builder Design Pattern solves these two problems by delegating the responsibility of object creation to special objects called builders.

The builder object composes the original object and breaks down the creation process into multiple stages or steps.

Each step is defined by a method in the builder object which initializes a subset of the object attributes based on some business logic.

Client code: we just need to use the builder and call the individual steps

The typical builder design pattern Structure

The typical builder design pattern consists of 4 main classes:

1. Builder: The builder interface should only define the construction methods without the build() method, which is responsible for returning the created entity.

   Because we are aiming to manage multiple builders sharing the same construction steps but implementing them in different ways.

   Each builder is free to return any shape of product as long as it's implementing all the steps defined in the Builder Interface.

2. Concrete Builder Classes: Each concrete Builder provides its own implementation of the Builder Interface methods so that it can produce its own variant of the object (instance of Product1 or Product2).

3. Client: You can think of the client as the top-level consumer of our objects, the user who is importing library modules or the entry point of our application.

4. Director: Even the same builder object can produce many variants of the object.

   Client code

As you can see from the code above, there is a big need for some entity to take the responsibility of directing or orchestrating the different possible combination sequences of calls to the builder methods, as each sequence may produce a different resulting object.

So can we further abstract the process and provide an even simpler interface for the client code?

That's where the Director class comes in. The director takes more responsibilities from the client and allows us to factor all of those builder sequence calls and reuse them as needed.

Client code

As you can see from the code above, the client code doesn't need to know about the details for creating prompt1 or prompt2. It just calls the director, sets the correct builder object, and then calls the makePrompt methods.

Practical Scenario

To further demonstrate the builder design pattern's usefulness, let's build a prompt engineering image generation AI CLI tool from scratch.

The source code for this CLI app is available here.

The CLI tool will work as follows:

1. The CLI will prompt the user to choose one style of prompts: Realistic or Digital Art.
2. Then it will ask the user to enter a subject for their prompt, for example: a cheese eating a burger.
3. Depending on your choice (Digital Art or Realistic), the CLI tool will create complex prompt objects with many configuration details.

The realistic prompt will need all of the following configuration attributes to be constructed.

file: prompts.ts

file: prompts.ts

As you can see here, each prompt type requires many complex attributes to be constructed, like artStyle, colorPalette, lightingEffect, perspective, cameraType, etc.

Feel free to explore all of the attribute details, which are defined in the enums.ts file of our project.

enums.ts

The user of our CLI app may not be aware of all these configurations; they may just want to generate an image based on a specific subject like cheese eating burger and style (Realistic or Digital Art).

After cloning the Github repository, install the dependencies using the following command:

After installing the dependencies, run the following command:

You'll be prompted to choose a prompt type: Realistic or Digital Art.

Then you will have to enter the subject of your prompt. Let's stick with cheese eating burger.

Depending on your choice, you will get the following text prompts as a result:

Realistic Style Prompt:

Digital Art Style Prompt:

Copy the previous commands and then paste them into ChatGPT. ChatGPT will use the DALL-E 3 model to generate the images.

Realistic Image Prompt Result

Digital Art Image Prompt Result

Remember the prompt parameters' complexity and the expertise needed to construct each type of prompt, not to mention the ugly constructor calls which are needed.

Disclaimer: This ugly constructor call is not a big issue in JavaScript because we can pass a configuration object with all the properties being nullable.

To abstract the process of building the prompt and make our code open for extension and closed for modification (O in SOLID), and to make using our prompt generation library seamless or easier for our library clients, we will be opting to implement the builder design pattern.

Let's start by declaring the generic prompt builder interface.

The interface declares a bunch of methods:

1. buildBaseProperties, buildTechnicalDetails, and buildArtisticElements are the steps for constructing either a Realistic or Digital Art prompt.
2. setSubject is a shared method between all of our prompt builders; it's self-explanatory and will be used to set the prompt subject.

builders.ts

builders.ts

As you can see from the implementations above, each builder chooses to build its own kind of prompt (the final prompt shapes are different) while sticking to the same building steps defined by the PromptBuilder contract!

Now, let's move on to our Director class definition.

director.ts

The Director class wraps a PromptBuilder and allows us to create a prompt configuration which consists of calling all the builder methods starting from setSubject to buildArtisticElements.

This will simplify our client code in the index.ts file, which we will see in the next section.

serializers.ts

To print the final prompt text to the terminal console, I've implemented some utility serialization functions.

Now our prompt library generation code is ready. Let's make use of it in the index.ts file.

index.ts

The code above performs the following actions:

1. Prompt the user to select a prompt style and then a subject using the inquirer package: getUserInput.
2. After getting both the subject and the art style from the user, the client code uses only two components from our library: The PromptBuilder and the Director.
3. We start by instantiating the Director.
4. Then, depending on the selected prompt style, we instantiate the corresponding builder and set it to the Director class.
5. Finally, we call the director.makePrompt method with the chosen subject as an argument, get the prompt from the builder, and print the serialized prompt to the terminal console.

   Remember: it's not possible to get the prompt from the director because the shape of the prompt produced by each builder type is different.

Conclusion

The Builder design pattern proves to be an excellent solution for creating complex objects with multiple configurations, as demonstrated in our AI image prompt generation CLI application. Here's why the Builder pattern was beneficial in this scenario:

1. Simplified Object Creation: The pattern allowed us to create intricate RealisticPhotoPrompt and DigitalArtPrompt objects without exposing their complex construction process to the client code.

2. Flexibility: By using separate builder classes for each prompt type, we could easily add new prompt types or modify existing ones without changing the client code.

3. Code Organization: The pattern helped separate the construction logic from the representation, making the code more modular and easier to maintain.

4. Reusability: The PromptDirector class allowed us to reuse the same construction process for different types of prompts, enhancing code reusability.

5. Abstraction: The client code in index.ts remained simple and focused on high-level logic, while the complexities of prompt construction were abstracted away in the builder classes.

Contact

If you have any questions or want to discuss something further, feel free to Contact me here.

Happy coding!