常量vs属性日志文件名

我有一个简单的导入器类，可将成功和失败状态记录到日志文件中。常量vs属性日志文件名

我所做的日志文件名称常量在类像这样：

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 
    } 
}

鉴于我目前没有用于不同的日志文件，第二种方法是否有任何好处？

来源

2013-08-29 Marty Wallace

你为什么用java标记这个？ – BackSlash

考虑到您的情况，唯一的好处就是您创建的模块化代码的个人满意度，并允许在不需要修改源代码的情况下实现不同的场景。 –

一方面你需要最少量的代码来提供所需的功能，另一方面你希望代码是模块化和可重用的。 – Anigel

我认为就日志记录而言，你不应该允许改变日志路径。不是在运行时 - 因为存在一个问题 - 如果日志路径将在热点上更改，数据完整性会发生什么？灵活性听起来不错，但我认为这不是一种情况，当你应该允许在运行时改变你的属性。

如果您对日志路径犹豫不决，那么它应该可以通过配置文件进行调整- 即在应用程序启动时读取一次。所以你不会在你的班级中存储路径，而是从配置文件中读取它（在你的班级__construct()中）。

来源

2013-08-29 12:39:58

如果您有一个不改变的静态日志文件路径，您可以留在第一个。

如果它应该能够改变日志路径（天气现在或计划未来），我会使用第二个。（好处是能够设置和获取logpath，一个getter也可以用于第一个解决方案）。

来源

2013-08-29 12:36:10

你的课可能违反了single responsibility principle：从doImport方法我认为你的类的第一个责任是导入，它不应该关注日志的细节（格式，使用什么文件，登录开发的内容/生产环境）。为什么不传入构造函数中的记录器类（最好是实现接口的类）？ Monolog是一个梦幻般和灵活的日志库。

如果你保持文件名（或更好的记录器）的灵活性，你可以为你的类编写单元测试，而不必担心重写重要文件。如果你使用内存/虚拟记录器类，你甚至不需要一个文件系统！

如果您只是编写一个不会被测试的小型一次性脚本，那么使用常量是配置IHMO的好方法。

来源

2013-08-29 12:47:33 chiborg

这是一个不容小觑的过程。第二种方法更灵活，更明确。此外，日志文件名称并不是一个“真正的”常数，例如pi或equator长度。当定义为常量时，它只是一个“魔法值”，你迟早会忘记它在那里。

虽然我摆脱了setter方法，只允许在构造函数中设置值。

来源

2013-08-29 12:47:33 lafor

常量vs属性日志文件名

回答

相关问题