Bir uygulamanın yanında günlüğe kaydetme bir SRP ihlali mi?

Çevik yazılım geliştirme ve tüm ilkeleri (SRP, OCP, ...) düşünürken kendime günlük kaydını nasıl tedavi edeceğimi soruyorum.

Bir uygulamanın yanında günlüğe kaydetme bir SRP ihlali mi?

yesUygulamanın günlüğe kaydetmeden de çalışabilmesi gerektiği için söyleyebilirim . Peki günlüğü nasıl daha iyi uygulayabilirim? Bazı desenleri kontrol ettim ve ilkeleri kullanıcı tanımlı bir şekilde ihlal etmemenin en iyi yolunun, prensibi ihlal ettiği bilinen herhangi bir deseni kullanmak, bir dekoratör deseni kullanmak olduğu sonucuna vardım.

Diyelim ki SRP ihlali olmadan bir sürü bileşenimiz var ve daha sonra günlük eklemek istiyoruz.

• bileşen A
• B bileşeni A kullanır

A için günlüğe kaydetmeyi istiyoruz, bu yüzden A ile süslenmiş başka bir D bileşeni oluşturuyoruz.

• arayüz I
• bileşen L (sistemin kayıt bileşeni)
• A bileşeni uygular I
• D bileşeni I'yi uygular, A'yı dekore eder / kullanır, günlüğe kaydetme için L kullanır
• B bileşeni bir I kullanır

Avantajları: - A'yı günlük kaydı olmadan kullanabilirim - test A Günlük kaydı alayına ihtiyacım olmadığı anlamına gelir - testler daha basittir

Dezavantaj: - daha fazla bileşen ve daha fazla test

Bunun başka bir açık tartışma sorusu olduğunu biliyorum, ama aslında birisinin bir dekoratör veya SRP ihlali yerine daha iyi kayıt stratejileri kullanıp kullanmadığını bilmek istiyorum. Varsayılan NullLogger gibi statik tekli logger ve syslog-logging isteniyorsa, çalışma zamanında uygulama nesnesini değiştirmeye ne dersiniz?

Evet , günlüğe kaydetme çapraz bir sorun olduğundan SRP'nin ihlalidir .

Doğru yol, günlüğe kaydetmeyi tek amaç SRP tarafından kaydedilmek olan bir logger sınıfına (Interception) devretmektir .

İyi bir örnek için bu bağlantıya bakın: https://msdn.microsoft.com/en-us/library/dn178467%28v=pandp.30%29.aspx

İşte olan kısa bir örnek :

public interface ITenantStore
{
    Tenant GetTenant(string tenant);
    void SaveTenant(Tenant tenant);
}

public class TenantStore : ITenantStore
{
    public Tenant GetTenant(string tenant)
    {....}

    public void SaveTenant(Tenant tenant)
    {....}
} 

public class TenantStoreLogger : ITenantStore
{
    private readonly ILogger _logger; //dep inj
    private readonly ITenantStore _tenantStore;

    public TenantStoreLogger(ITenantStore tenantStore)
    {
        _tenantStore = tenantStore;
    }

    public Tenant GetTenant(string tenant)
    {
        _logger.Log("reading tenant " + tenant.id);
        return _tenantStore.GetTenant(tenant);
    }

    public void SaveTenant(Tenant tenant)
    {
        _tenantStore.SaveTenant(tenant);
        _logger.Log("saving tenant " + tenant.id);
    }
}

Yararları

• Bunu giriş yapmadan test edebilirsiniz - gerçek birim testi
• günlükte bile kolayca açıp kapatabilirsiniz
• TenantStore dosyasını değiştirmek zorunda kalmadan günlüğe kaydetmenin diğer günlük biçimleri yerine kullanabilirsiniz.

SRP'yi çok ciddiye aldığınızı söyleyebilirim. Eğer kodunuz SRP'nin tek "ihlali" olacak kadar düzenli ise, o zaman diğer tüm programcıların% 99'undan daha iyi bir performansa sahip olursunuz.

SRP'nin amacı, farklı şeyler yapan kodun hep birlikte karıştığı korkunç spagetti kodundan kaçınmaktır. Günlüğe kaydetmeyi işlevsel kodla karıştırmak benim için alarm zili çalmaz.

Hayır, SRP'nin ihlali değildir.

Günlüğe gönderdiğiniz iletiler, çevresindeki kodla aynı nedenlerle değişmelidir.

SRP'nin ihlali, doğrudan kodda oturum açmak için belirli bir kitaplık kullanmaktır. Oturum açma yöntemini değiştirmeye karar verirseniz, SRP bunun iş kodunuzu etkilememesi gerektiğini belirtir.

Bir tür özetin Loggeruygulama kodunuz tarafından erişilebilir olması gerekir ve uygulamanızın söylemesi gereken tek şey, "Bu iletiyi günlüğe gönder" dir ve nasıl yapıldığından endişe duymazsınız. Tam günlüğe kaydetme yöntemine (zaman damgası bile) karar vermek uygulamanızın sorumluluğu değildir.

Uygulamanız, mesaj gönderdiği kaydedicinin a NullLogger.

Bahsedilen.

Kesişen bir endişe olarak çok hızlı bir şekilde günlüğe kaydetmeyi fırçalamam . Uygulama kodunuzda meydana gelen belirli olayları izlemek için günlük yayan uygulama koduna aittir.

Kesişen bir sorun olan OTOH, yürütme izlemesidir : günlük tutma her yönteme girer ve çıkar. AOP bunu yapmak için en iyi yerdir.

Günlüğe kaydetme genellikle kesişen bir endişe olarak görüldüğünden, günlüğe kaydetmeyi uygulamadan ayırmak için AOP kullanmanızı öneririm.

Dile bağlı olarak, bunu gerçekleştirmek için bir önleyici veya bazı AOP çerçevesi (örn. Java'daki AspectJ) kullanırsınız.

Soru, bunun gerçekten güçlük çekmeye değip değmeyeceği. Bu ayrımın çok az fayda sağlarken projenizin karmaşıklığını artıracağını unutmayın.

Kulağa hoş geliyor. Oldukça standart bir günlük dekoratörünü tarif ediyorsunuz. Var:

bileşen L (sistemin kayıt bileşeni)

Bunun bir sorumluluğu vardır: kendisine iletilen bilgilerin günlüğe kaydedilmesi.

A bileşeni uygular I

Bunun bir sorumluluğu vardır: arayüz I'in uygulanmasını sağlamak (I'nin SRP uyumlu olduğu varsayılırsa, yani).

Bu çok önemli kısım:

D bileşeni I'yi uygular, A'yı dekore eder / kullanır, günlüğe kaydetme için L kullanır

Bu şekilde ifade edildiğinde, kulağa karmaşık geliyor, ama şu şekilde bakın: D bileşeni bir şey yapar : A ve L'yi bir araya getirmek.

• D bileşeni günlüğe kaydetmiyor; bunu L'ye devrediyor
• D bileşeni I'in kendisini uygulamıyor; bunu A'ya delege eder

Sadece bileşen D sahip olduğu sorumluluk emin bir kullanıldığında L bildirilir olduğunu yapmaktır. A ve L'nin her ikisi de başka yerlerdedir. Bu tamamen SRP uyumludur, yanı sıra düzgün bir OCP örneği ve oldukça yaygın bir dekoratör kullanımıdır.

Önemli bir uyarı: D senin günlüğü bileşeni L kullandığında, bu değiştirmek sağlayan bir şekilde böyle yapmalı nasıl sen günlüğü. Bunu yapmanın en basit yolu, L tarafından uygulanan bir arabirim IL'ye sahip olmaktır.

• Bileşen D, oturum açmak için bir IL kullanır; L örneği sağlanmıştır
• Bileşen D, işlevsellik sağlamak için bir I kullanır; A örneği sağlanır
• B bileşeni bir I kullanır; D örneği sağlanmıştır

Bu şekilde, hiçbir şey doğrudan başka bir şeye bağlı değildir, bu da onları değiştirmeyi kolaylaştırır. Bu, üniteyi test edebilmeniz için değişikliğe adapte olmayı ve sistemin parçalarını taklit etmeyi kolaylaştırır.

Elbette, çapraz kesişme endişeniz olduğu için SRP'nin ihlali. Bununla birlikte, herhangi bir eylemin yürütülmesiyle günlük kaydını oluşturmaktan sorumlu bir sınıf oluşturabilirsiniz.

misal:

class Logger {
   ActuallLogger logger;
   public Action ComposeLog(string msg, Action action) {
      return () => {
          logger.debug(msg);
          action();
      };
   }
}