过程式无类型语言下双状态参数接口最优实现版本咨询

Hey there,

It sounds like you’re caught between two subpar interface options for your procedural, typeless language—Version 1 is clean but unreadable for callers, and Version 2 just doesn’t sit right with you. Let’s break down a couple of better alternatives that balance readability, simplicity, and maintainability, tailored to your language’s constraints:

Option 1: Semantically Named Wrappers with Shared Core Logic #

Since you can’t lean on classes or types to clarify intent, use explicit function names to encode the state directly. Extract the shared logic into a private helper function to avoid redundancy, then expose two purpose-built public functions.

Example code:

# Private helper: handles logic common to both states
_doSthCore(par1) {
    // Shared implementation here
    ...
}

# Public functions for each state
doSthForStateX(par1) {
    _doSthCore(par1);
    // State X-specific logic
    ...
}

doSthForStateY(par1) {
    _doSthCore(par1);
    // State Y-specific logic
    ...
}

Pros: #

• Callers never have to guess what state parameter to pass—function names make intent crystal clear.
• No redundant code thanks to the shared core.
• Easy to modify or extend individual state behaviors later.

Cons: #

• If you ever need to add more states, you’ll have to create new functions (but since you only have two right now, this is a minor tradeoff).

Option 2: Semantic State Identifiers + Single Entry Point #

If you prefer keeping a single function, replace "magic values" for the state parameter with named constants (or well-documented global variables, if your language doesn’t support constants). This keeps the function’s surface small while making calls readable.

Example code:

# Define semantic state labels (use constants if your language allows)
STATE_X = "state_x"
STATE_Y = "state_y"

doSth(par1, state) {
    if state == STATE_X {
        // State X logic
        ...
    } elif state == STATE_Y {
        // State Y logic
        ...
    } else {
        // Handle invalid state (critical for typeless languages!)
        ...
    }
}

# Caller usage (no more mystery parameters!)
doSth("input_value", STATE_X)

Pros: #

• Maintains a single function entry point, keeping your API concise.
• Eliminates guesswork for callers—they use named identifiers instead of arbitrary values.
• Easier to add new states later (just define a new identifier and add an elif branch).

Cons: #

• Callers still have to pass the state parameter, but the semantic labels make this far less error-prone than raw magic values.

Option 3: Optional State Parameter with Default (If Supported) #

If your procedural language supports optional parameters or default values, you can combine the best of both worlds: keep a single function, set the most common state as the default, and let callers specify the other state only when needed.

Example code:

STATE_X = "state_x"
STATE_Y = "state_y"

# Default to State X (adjust based on your usage patterns)
doSth(par1, state=STATE_X) {
    if state == STATE_X {
        ...
    } elif state == STATE_Y {
        ...
    }
}

# Caller usage:
doSth("common_case_input") // Uses default State X
doSth("special_case_input", STATE_Y) // Explicitly uses State Y

Pros: #

• Super clean for the most frequent use case (no extra parameter needed).
• Still explicit when the non-default state is required.
• Keeps code centralized in one function.

Cons: #

• Only works if your language supports optional/default parameters—if not, stick to Option 1 or 2.

Which to Choose? #

• Go with Option 1 if the two states represent fundamentally different actions (callers shouldn’t have to think about "state" at all).
• Pick Option 2 if it’s the same core action with minor behavioral differences, and you might add more states later.
• Use Option 3 if one state is vastly more common than the other, and your language supports defaults.

Hope one of these fits your needs better than the original two versions!

内容的提问来源于stack exchange，提问作者Groudonx