Allow One Function Call - Video Solutions

Problem Overview: You need to wrap an existing function so it can be executed only once. The first call runs the original function and returns its result. Every later call must return undefined without executing the function again.

This is a classic function wrapper problem. The wrapper keeps track of whether the underlying function has already been executed. Once the first invocation happens, all later calls are ignored. The challenge is managing that state efficiently while preserving the original function's arguments.

Approach 1: Use a Closure to Track Calls (O(1) time, O(1) space)

The most common solution uses a closure that stores whether the function has already been executed. Create a boolean variable such as called inside the outer function. The returned inner function checks this flag before executing the original function. If called is false, invoke the function using the provided arguments and update the flag to true. If it is already true, simply return undefined.

This works because closures preserve access to variables from their enclosing scope even after the outer function returns. Each wrapped function instance gets its own independent state. The runtime cost is constant since each invocation performs only a flag check and possibly a single function call. This pattern is widely used in closures, higher-order functions, and JavaScript-style functional utilities.

Approach 2: Flag with External State (O(1) time, O(1) space)

Languages like C or C++ do not have built-in closures in the same way as JavaScript or Python. Instead, store the execution state in a variable outside the wrapper function or inside a small struct/object. The wrapper checks this shared flag before executing the original function pointer.

The logic is identical to the closure approach: check the flag, execute the function once, then permanently flip the flag. The difference is how the state is stored and passed around. This method appears in lower-level languages where function wrappers rely on explicit state management instead of lexical scope. It still runs in constant time with constant memory usage.

Problems like this appear frequently in API design and functional utilities where you want a side-effect to occur only once. Examples include initializing configuration, running startup logic, or protecting expensive operations.

Recommended for interviews: The closure-based approach is the expected answer in JavaScript, Python, and Java interviews. It demonstrates understanding of lexical scope, higher-order functions, and state captured inside a wrapper. Mentioning the external state approach shows awareness of how the same design works in languages without native closures. Both solutions run in O(1) time and O(1) space, but the closure version is cleaner and idiomatic for modern function design problems.