我有一个简单的导入程序类，它将成功和失败状态记录到日志文件中。
我已经将日志文件名设置为类中的常量，如下所示：
class MyClass
{
const STATUS_LOG = "my_log.log";
public function doImport()
{
// do import here and log result
}
}
目前我不知道为什么会使用不同的日志，但允许这种灵活性并做以下事情会更好吗：
class MyClass
{
private $statusLog;
public function __construct($statusLog)
{
$this->statusLog = $statusLog;
}
public function getStatus()
{
return $this->statusLog;
}
public function setStatusLog($statusLog)
{
$this->statusLog = $statusLog;
}
public function doImport()
{
// do import here and log result
}
}
鉴于我目前不使用不同的日志文件，第二种方法有什么好处吗？
我认为在日志方面，不应该允许更改日志路径。不在运行时——因为有一个问题——如果日志路径"热"更改，数据完整性会发生什么？灵活性听起来不错，但我认为在运行时不应该允许更改属性。
如果您对日志路径犹豫不决，那么它应该可以通过配置文件进行调整，即在应用程序启动时读取一次。因此，您将不会在类中存储路径，而是从配置中读取路径（在类的__construct()中）。
如果您有一个不变的静态日志文件路径，您可以停留在第一个路径。
如果它能够更改日志路径（现在的天气或计划的未来），我会使用第二个。（好处只是能够设置和获取logpath，getter也可以用于firse解决方案）。
这是一个很容易的问题。第二种方法更加灵活和明确。此外，日志文件名并不是一个"真正的"常量，例如pi或赤道长度。当定义为常量时，它只是一个"神奇的值"，你迟早会忘记它的存在。
不过，我会去掉setter方法，只允许在构造函数中设置值。
您的类可能违反了单一责任原则：根据doImport方法，我得出结论，您的类的第一责任是导入，它不应该关心日志记录的细节（格式化、使用什么文件、在开发/生产环境中记录什么）。为什么不在构造函数中传递一个记录器类（最好是实现PSR-3接口的类）？Monolog是一个奇妙而灵活的日志库。
如果你保持文件名（或者更好的是记录器）的灵活性，你就可以为你的类编写单元测试，而不必担心覆盖重要的文件。如果您使用内存/虚拟记录器类，您甚至不需要文件系统！
如果您只是编写一个不会进行测试的一次性小脚本，那么使用常量是配置IHMO的好方法。