During the coding, we often need to make some configuration on “object” or “entity”. In Golang’s world, the following example:
type Server struct {
Addr string
Port int
Protocol string
Timeout time.Duration
MaxConns int
TLS *tls.Config
}
In this example, we will see
must, if it is not present with explicit value, they will resolve to the default value, f.g Addr will be resolved with localhost, Port will be resolved with some specified value which depended on the type of protocol.In typical server implementation, the following code will be provided with different types of scenarios.
In the “src/net/http/httptest/server.go” file, the following function was provided:
func NewDefaultServer(addr string, port int) (*Server, error) {...}
func NewTLSServer(addr string, port int, tls *tls.Config) (*Server, error) {..}
func NewServerWithTimeout(addr string, port int, timeout time.Duration) {...}
func NewTLSServerWithMaxConnAndTimeout(addr string, port int, maxconns int, timeout time.Duration, tls *tls.Config) (*Server, error) {...}
In the C++ world, the common pattern is using overloaded constructors with the same name (name of the class) and different number of argument. or using a Factory pattern to make it.
Cons: This method have some cons that it didn’t have a friend usage to the user, not flexible enough if more argument are needed in the future.
As we mentioned above, during the initialization, some parameters are must, then we separate them with other unnecessary options, and wrap those options with a separate object such like this one:
type Config struct {
Protocol string
Timeout time.Duration
Maxconns int
TLS *tls.Config
}
So, the constructor will be like this:
func NewServer(addr string, port int, conf *Config) (*Server, error) {...}
Class Server::Server(std::string addr, int port, Config* config) {...}
In the body of the constructor or helper functions, we need check the availability of each element in the config.
Cons: Not flexible, introduce a new struct to try help us but not much benefit with this.
In the “Effective C++”, Scott Mayer introduce to use a standalone “builder” to make this.
Class Server::Builder {
Addr string
Port int
Protocol string
Timeout time.Duration
MaxConns int
TLS *tls.Config
};
Builder::Add(std::string addr) { this->Addr = addr; }
Builder::Port(int port) { this->Port = port; }
//Checking the constraints on the parameters , and if OK, try to build a new Server.
//or if NOT, return nullptr
Server* Builder::Build() {}
Server* newServer = Server::Builder().Add("localhost").Port(8080).Build();
Cons: It didn’t help us from releasing the build work, instead moving such work from Server to another Builder helper.
Idiomatic Golang use Functional Options to address such problems,
// Define a type of function
type Option func(*Server)
// Define the following functions
func Protocol(p string) Option {
return func(s *Server) {
s.Protocol = p
}
}
func Timeout(t time.Duration) Option {
return func(s *Server) {
s.Timeout = t
}
}
func TLS(t *tls.Config) Option {
return func(s *Server) {
s.TLSConfig = t
}
}
Golang and >=C++11 can take the function as the first citizen, they can be passed to the function as the normal argument. The idea is tightly coupled with only necessary parameter in the minimum scope function, transform from a previous one to a new one.
Now we define a NewServer() function with must parameter and transform parameter.
func NewServer(addr string, port int, opts ...Option) (*Server, error) {
srv := &Server{
Addr: addr,
Port: port,
Protocol: "tcp",
Timeout: 30 * time.Second,
MaxConns: 1000,
TLS: nil
}
for _, opt := range opts {
opts(srv)
}
return src, nil
}
So, we can make the following example:
s1, _ := NewServer("127.0.0.1", 8080)
s2, _ := NewServer("127.0.0.1", 8081, Protocol("udp"))
s3, _ := NewServer("127.0.0.1", 8082, Protocol("tcp"), Timeout(10 * time.Second))
much better, ha?! But how about the constraints on the parameters? such like NewTLSServer(…) ? f.g TLSConfig must be with the protocol with “tls”, or binding to a ranged parameter?
func TlsConfig(tls *tls.Config) Option {
return func(s *Server) {
s.Protocol = "tls"
s.TLSConfig = tls
}
}
s4, _ := NewServer("127.0.0.1", 8081, TlsConfig(tls, 10 * time.Second))
We can make a specified Option in this scenario.
Then in the >=c++11, we can make it as well:
namespace go {
using std::string;
namespace time {
using Duration = int64_t;
constexpr auto Second = 1LL;
}
namespace tls {
using Config = string;
}
struct Server {
string addr;
int port;
string protocol;
time::Duration timeout;
int max_conns;
tls::Config *tls_;
};
using Option = std::function<void(Server &s)>;
auto Protocol(string p) -> Option
{
return [p](Server &s) { s.protocol = p; };
}
auto Timeout(time::Duration timeout) -> Option
{
return [timeout](Server &s) { s.timeout = timeout; };
}
auto MaxConns(int max_conns) -> Option
{
return [max_conns](Server &s) { s.max_conns = max_conns; };
}
auto TLS(tls::Config *tls_) -> Option
{
return [tls_](Server &s) { s.tls_ = tls_; };
}
Server NewServer(string addr,
int port,
std::initializer_list options = {})
{
Server s{ addr, port };
for (auto &option : options) {
option(s);
}
return s;
}
void UsageServer()
{
auto s1 = NewServer("localhost", 1024);
auto s2 = NewServer("localhost", 2048, { Protocol("udp") });
auto s3 = NewServer("0.0.0.0", 8080,
{ Timeout(300 * time::Second), MaxConns(1000) });
}
}
[Ref] “Self referential functions and design” by Rob Pike http://commandcenter.blogspot.com.au/2014/01/self-referential-functions-and-design.html