Proposal: Reduce Global Variables and Adopt the Options Pattern for Configuration Management

[0x0001]

Context

I've noticed that the project currently uses some global variables to manage configuration or state in certain modules. While convenient, this can introduce challenges for testing, potential state conflicts, and maintainability.

Proposal

Consolidate the existing global variables into non-global configuration structs, and initialize/pass this configuration using the Options Pattern (also known as Functional Options).

Example Reference

// Proposed usage
client := binance.New(
    binance.WithHMAC("apiKey", "secret"),
    binance.WithTestnet(),
    // ... other configuration options
)

Benefits

• Reduced Side Effects: Explicitly passing dependencies, avoiding implicit global state.
• Improved Testability: Easy to inject different configurations for different test cases.
• Enhanced Readability & Flexibility: Configuration options are passed via explicit function arguments, making code intent clearer and easier to extend with new options.

Next Steps

I would be very happy to implement this change once we reach a consensus.

I'd first like to hear the thoughts of the maintainers and community members:

1. Does this direction align with the project's long-term architectural goals?
2. Are there any potential concerns we should be particularly mindful of?

[sc0Vu]

I wonder whether the functional options is a good way. You must call multiple function in a loop somewhere. How do you think if we use function config. For example,

type Config struct {
    testnet bool
    debug bool
    ......
}

func (c *Config) WithTestnet(b bool) *Config {
    c.testnet = b
    return c
}

func (c *Config) WithDebug(b bool) *Config {
    c.debug = b
    return c
}

func NewConfig(testnet, debug bool) *Config {
    c := new(Config)
    c.testnet = testnet
    c.debug = debug
    return c
}

[0x0001]

@sc0Vu

1. The function option also allows the user to set many variables at once, if he knows the implementation details.
2. For direct users, there is no need to know that there is a Config process, which reduces the number of concepts that need to be understood.

for example

type Opts struct {
	Endpoint string
	Debug    bool
}

type Opt func(*Opts)

func WithEndpoint(endpoint string) Opt {
	return func(o *Opts) {
		o.Endpoint = endpoint
	}
}

func WithDebug() Opt {
	return func(o *Opts) {
		o.Debug = true
	}
}
func WithTestnet() Opt {
	return func(o *Opts) {
		o.Endpoint = "https://testnet.example.com"
	}
}

type DemoClient struct {
	endpoint string
	debug    bool
}

func newDefaultOpts() *Opts {
	return &Opts{
		Endpoint: "https://mainnet.example.com",
		Debug:    false,
	}
}

func New(opts ...Opt) *DemoClient {
	o := newDefaultOpts()
	for _, opt := range opts {
		opt(o)
	}
	return &DemoClient{
		endpoint: o.Endpoint,
		debug:    o.Debug,
	}
}

func TestNewClient(t *testing.T) {
	client := New(
		WithDebug(), WithTestnet(),
	)

// The function option also allows the user to set many variables at once, if he knows the implementation details.
	client = New(func(o *Opts) {
		o.Endpoint = ""
		o.Debug = true
	})

	_ = client
}

[sc0Vu]

@0x0001 How do you think we do it without closures? Based on this https://github.com/uber-go/guide/blob/master/style.md#functional-options, it's more easier to debug and test.

[0x0001]

@0x0001 How do you think we do it without closures? Based on this https://github.com/uber-go/guide/blob/master/style.md#functional-options, it's more easier to debug and test.

I think interface is just more boilerplate code than closure in this scenario, and it doesn't bring more flexibility.

Using closure is not more difficult to debug and test.

I think one thing that makes interface better than closure is that you can add new methods to separate the process, such as adding precheck, postcheck methods, and splitting parts of the code into different functions.

There's probably something else I don't know, so feel free to chime in.