常量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屬性日誌文件名

回答

相關問題