日志库中同时实现静态与非静态同名方法是否为不良设计？

答案是肯定的，这种同时在类中提供同名静态与非静态成员方法的设计存在不少潜在问题，属于需要谨慎规避的不良实践，具体问题如下：

1. 可读性与歧义风险 #

完全相同的方法名会让开发者混淆两者的行为边界：看到logger::critical()时，新手可能会误以为这是操作某个当前实例的静态方法，而非全局默认实例；反过来，也可能有人在持有自定义实例时错误调用静态方法，导致日志输出到了全局实例而非预期的自定义实例。这种歧义在团队协作场景下会显著增加理解成本和出错概率。

2. 维护成本飙升 #

每一个日志级别方法都需要实现两份逻辑（静态版和非静态版），后续如果要新增日志级别、修改方法参数（比如添加日志上下文）、调整输出逻辑，必须同时修改静态和非静态版本，很容易出现遗漏，导致全局实例和自定义实例的行为不一致。

3. 违反单一职责原则 #

你的logger类现在同时承担了两个职责：

• 管理单个日志实例的配置与日志输出
• 管理全局默认日志实例的配置与日志输出
  一个类承担多项职责会让代码耦合度变高，后续扩展或修改时容易牵一发而动全身。

更优的替代方案 #

要实现「支持自定义实例+全局默认实例」的需求，有几种更清晰、符合设计原则的方案：

方案1：拆分全局实例管理到单独入口 #

在命名空间下提供一个获取默认实例的函数，logger类只保留非静态方法，专注于单个实例的逻辑：

namespace lwlog {
    // 全局默认实例的获取函数
    std::shared_ptr<logger> default_logger() {
        static auto instance = std::make_shared<logger>("DEFAULT");
        return instance;
    }
}

// 调用方式
std::shared_ptr<lwlog::logger> core_logger = std::make_shared<lwlog::logger>("LOGGER");
core_logger->critical("A very critical message!"); // 自定义实例调用
lwlog::default_logger()->critical("A very critical message!"); // 全局实例调用

方案2：静态工厂方法获取默认实例 #

如果希望把默认实例的入口放在类内部，可以添加一个静态方法返回默认实例，而非重复实现所有日志方法：

class LWLOG logger {
public:
    explicit logger(const std::string& name);
    ~logger();
    // ... 非静态配置与日志方法 ...
    void critical(const std::string& message);

    // 静态方法仅负责提供默认实例
    static std::shared_ptr<logger> default_instance() {
        static auto instance = std::make_shared<logger>("DEFAULT");
        return instance;
    }
};

// 调用方式
logger::default_instance()->critical("A very critical message!");

方案3：命名空间级别的包装函数 #

直接在命名空间下提供全局日志函数，内部调用默认实例的方法，让全局调用更简洁：

namespace lwlog {
    void critical(const std::string& message) {
        default_logger()->critical(message);
    }
    // 同理实现info/warning/error等方法
}

// 调用方式
lwlog::critical("A very critical message!"); // 全局日志
core_logger->critical("A very critical message!"); // 自定义实例日志

这些方案都拆分了职责，避免了同名方法的歧义，同时让代码更易读、易维护。

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