When to Break and When to Build: Practical Examples | Organizing Your Thoughts: Functions and Modularity | Introduction to Computer Algorithm: Data Structures, Complexity, and Optimization for Modern AI Systems

In our journey through algorithms, we've learned that breaking down complex problems into smaller, manageable pieces is key. But how do we know when to break a problem into separate functions and when to keep related logic together? It's a balance between creating too many tiny, disconnected pieces and having one giant, unreadable block of code. Let's explore some practical examples to build your intuition.

Consider a program that needs to process user input, perform a calculation, and then display the result. We can easily see three distinct responsibilities here. Each of these could be a good candidate for its own function.

graph TD
    A[Start Program] --> B(Get User Input)
    B --> C(Perform Calculation)
    C --> D(Display Result)
    D --> E[End Program]

Here's how this might look in code. Notice how each responsibility is encapsulated in its own function:

getUserInput() performCalculation(data) displayResult(result)

This makes our main program flow much clearer and allows us to test or reuse each part independently.

function getUserInput() {
  // Logic to get input from the user
  return userInputData;
}

function performCalculation(data) {
  // Logic to process data and calculate a result
  return calculatedResult;
}

function displayResult(result) {
  // Logic to show the result to the user
  console.log("The result is: " + result);
}

// Main program flow
const userData = getUserInput();
const finalResult = performCalculation(userData);
displayResult(finalResult);

Now, let's think about when not to break things apart. If a set of operations are very tightly coupled, meaning they almost always happen together and are hard to imagine doing separately, it might be better to keep them within a single function or a very small, cohesive set of functions. For example, if you have a function that validates a specific data format and then immediately parses it, and these two steps are intrinsically linked to that format, creating separate functions might add unnecessary overhead and reduce clarity.

Imagine a function whose sole purpose is to format a date for a specific report. This might involve extracting the day, month, and year, and then assembling them into a particular string format. While you could create a function for extracting the day, another for the month, etc., if these are only ever used in this specific formatting context, it might be simpler to keep them together. The key is 'cohesion' – how related are the tasks within a single unit of code?