Bir uygulamada neden statik günlük yöntemleri kullanmak yerine bir Logger nesnesi oluşturmalısınız?

Basit bir Ruby on Rails uygulaması örneği almak. LoggerUygulama yükleme işlemi sırasında bir nesne oluşturur :

# in environment.rb
config.logger = Logger.new(<STDOUT | file | whatever>)

# and in our application we use this object
logger.warn "This process is taking too long to process. Optimization needed."

Benim sorum, neden günlüğe kaydetme için sınıf yöntemleri (veya statik yöntemler) kullanmıyoruz? Olmaz Logger.warndaha ölçeğe Logger.new.warn? Ya da en azından Logger.warnsezgisel görünüyor Logger.new.warn.

Tek Logger.newbir nesne olsa bile , ne gibi avantajlar sunar?

İşte Java kullanan bir örnek. Log4j kullandığımdan bu yana bir süre geçti, ancak hatırladığım kadarıyla, tüm log4j günlük aracı bir XML dosyasından başlatılacaktı. XML dosyasının kendisi farklı yapılandırmalara sahip birden çok günlükçü içerebilir (nereye yazdığınız, hangi düzeylerin yazıldığı vb.). Bu durumda, hangi günlükçüyü çağırmak istediğinizi belirtmek için günlükçü statik yöntemleri yerine günlükçü nesneleriniz olur. Yani.

Logger logger = Logger.get("Network");

ağ bağlantısı, bırakılan paketler vb. ile ilgili şeyleri kaydeder veya

Logger logger = Logger.get("Application");

iş mantığınız / uygulamanızla ilgili şeyleri kaydeder. En azından log4j ile hangi günlük düzeylerinin gerçekten yazılacağını da yapılandırabilirsiniz (bilgi, izleme, uyarma, hata, hata ayıklama varsayılan düzeylerdir).

Statik yöntemleriniz varsa, yapabileceğiniz en iyi şey, standart dışı, dosya vb. Günlükçü nesneleriyle, günlükleme bilgilerinizin birden çok dosyaya dağıtılması için bunu yapmak daha kolaydır.

Logger.new, sonucun kullanılacağı yeri alacak bir fabrikadır (sınıfın / dosyanın adı).

Yapılandırma dosyalarında, projeyi yeniden derlemek zorunda kalmadan programın bazı bölümleri için günlüğe kaydedilmeyecek düzeyi günlüğe karar verebilirsiniz.

Böylece, sürüm derlemeleri için tüm yüksek düzeyli günlük kaydı (hatalar) dışında devre dışı bırakabilir ve yalnızca hata ayıkladığınız parçalar için en düşük düzeyi etkinleştirebilirsiniz.

Statik yöntem çağrısından mümkün olduğunca kaçınılmalıdır. Uygun Bağımlılık Enjeksiyonuna antika bir alternatiftir ve daha büyük bir kod tabanında yararlı bulacağınız bir şey değildir.

Örneğin test edilebilirliği düşünün. Statik olarak günlüğe kaydetmeyi başlatan Konu, hangi günlüklendirme sınıfının kullanıldığını kontrol altına alır - Denetimi Tersine Çevirme yoktur. Buraya sahte bir nesne veya herhangi bir tür sahte enjeksiyon yapma imkanı yoktur. Kaydediciyi SUT içine enjekte ederek, kaydediciyi alay etme ve enjekte etme seçeneğiniz olduğunu göreceksiniz.

Tartışılan statik yöntem çağırma türünde DI kullanmanın faydaları elbette test edilebilirliğin de ötesine geçer. Sisteminizde iki farklı kaydediciye sahip olmak isterseniz ne olacağını ve mevcut kodu düzenlemeden yalnızca nesne grafiğinin yapılandırılması yoluyla uygulama davranışını değiştirme seçeneğini düşünün.

Genel olarak, bir DI yaklaşımı denemenizi öneririm, bu yüzden kodunuzu daha sonra denenemez ve kullanışsız bulmazsınız.