DRYing up an initialization pattern I maintain a VBA process that prints a large number of PDFs. It was awful when I inherited it and I've been making improvements over time, but I'm a bit stuck on this one. There are at least 4 functions with this exact same code used to check to see if the program has been initialized properly. They could all be called individually, or together depending on circumstances.

I do not want to initialize again if I don't have to. Hence the check in every subroutine, but I just can't figure out how to do it any differently. Thoughts? Is there a design pattern to deal with this kind of thing that I don't know of?

Please try to focus on the pattern and not the supporting intitializer. I know there are a few issues there and intend to deal with them soon. I included it in case it was relevant.

Main code:

Private rootDir As String
Private isInit As Boolean
Private mCycle As String

Public Function printPDF_VoidedNewItems()
    If Not isInit Then
        initialize
    End If
    If rootDir &lt;&gt; "" And mCycle &lt;&gt; "" Then
        If setPrinterToPDF() Then
            ' logic specific to printing this pdf
        End If
    End If
End Function

Public Function printPDF_ComsNotFed()
    If Not isInit Then
        initialize
    End If
    If rootDir &lt;&gt; "" And mCycle &lt;&gt; "" Then
        If setPrinterToPDF() Then
            ' logic specific to printing this pdf
        End If
    End If
End Function


Initializer:

Private Sub initialize()
    rootDir = folderPicker() &amp; "\"
    mCycle = getCycleInput
    isInit = True
End Sub

Private Function folderPicker() As String
'*******************************************
' returns directory path to be printed to
'   does not allow multiple selections,
'   so returning the first item in selected
'   items is sufficient.
'
' returns empty string On Error or if the
'   user cancels
'********************************************
On Error GoTo ErrHandler

    Dim folderChosen As Integer
    Dim fd As Variant
    Set fd = Application.FileDialog(msoFileDialogFolderPicker)
    With fd
        .AllowMultiSelect = False
        .Title = "Choose Directory to Print to"
        .InitialFileName = "\\server\share\"
        .InitialView = msoFileDialogViewSmallIcons
        folderChosen = .Show
        If folderChosen &lt;&gt; -1 Then
            folderPicker = ""
        Else
            folderPicker = .SelectedItems(1)
        End If
    End With
Exit Function

ErrExit:
    folderPicker = ""
    Exit Function
ErrHandler:
    MsgBox "Unexpected Error: " &amp; Err.number &amp; vbCrLf &amp; "Source: " &amp; Err.Source &amp; _
        "Description: " &amp; Err.Description, vbCritical, "ERROR!"
End Function

Private Function getCycleInput() As String
' Displays a form with a combo box to the user.
' Returns an empty string if canceled or errored
'   Otherwise returns 8 character Cycle from dbo.MAM_ISE_SCHEDULE
On Error GoTo ErrHandler

    Dim cpkr As New Form_CyclePicker

    'wait for user input
    Do Until cpkr.Cancel = True Or cpkr.Confirmed = True 'Do Until user clicks "OK" or "Cancel"
        DoEvents 'frees up OS to actually display form and allow user to interact with it
    Loop

    If cpkr.Cancel Or Not cpkr.Confirmed Then ' not confirmed seems redundant, but certainly can't hurt to check.
        ' return
        getCycleInput = ""
        GoTo ExitSub
    Else
        ' return
        getCycleInput = cpkr.CycleNumber
    End If

ExitSub:
    Set cpkr = Nothing
    Exit Function
ErrHandler:
    MsgBox Err.Description, vbCritical, "Runtime Error: " &amp; Err.number
    getCycleInput = ""
    Resume ExitSub
End Function
Down with the underscore
I find the naming of printPdf_xxxx functions confusing, because if that code is/were in a class module they should be private, and the class would say Implements printPdf, where printPdf would be a class with VoidedNewItems and  ComsNotFed members... or it could be that there's a private field called printPdf that's declared WithEvents and the functions are event handlers made public.
Avoid underscores in procedure &amp; function (/method) names, the language has a meaning for identifiers with an underscore.

Initializing once
If you scratch that code and implement it in a class instead, and run initialisation in the... Class_Initialize method, which can be thought of as a parameterless constructor that runs when you create the object. Not too crazy about spawning a UI prompt in that handler though, but then the methods wouldn't have to worry about whether or not Initialize has executed.