구현 옆에 로깅이 SRP 위반입니까?

민첩한 소프트웨어 개발과 모든 원칙 (SRP, OCP 등)을 생각할 때 로깅 처리 방법을 스스로에게 묻습니다.

구현 옆에 로깅이 SRP 위반입니까?

yes로깅없이 구현을 실행할 수도 있기 때문에 말할 것 입니다. 어떻게 로깅을 더 나은 방법으로 구현할 수 있습니까? 몇 가지 패턴을 확인하고 사용자 정의 방식으로 원칙을 위반하지 않는 가장 좋은 방법은 원칙을 위반하는 것으로 알려진 패턴을 사용하는 것이 데코레이터 패턴을 사용하는 것입니다.

SRP 위반없이 많은 구성 요소가 있고 로깅을 추가하려고한다고 가정하겠습니다.

• 성분 A
• 성분 B는 A를 사용합니다.

A에 대한 로깅을 원하므로 인터페이스 I을 구현하는 A로 장식 된 다른 구성 요소 D를 만듭니다.

• 인터페이스 I
• 구성 요소 L (시스템의 로깅 구성 요소)
• 컴포넌트 A는 I를 구현
• 컴포넌트 D는 I를 구현하고 A를 장식 / 사용하며 로깅에 L을 사용합니다.
• 성분 B는 I를 사용합니다.

장점 :-로깅없이 A를 사용할 수 있습니다-테스트 A는 로깅 모의가 필요하지 않음을 의미합니다-테스트가 더 간단합니다.

단점 :-더 많은 구성 요소와 더 많은 테스트

나는 이것이 또 다른 공개 토론 질문 인 것으로 알고 있지만 실제로 누군가가 데코레이터 또는 SRP 위반보다 더 나은 로깅 전략을 사용하고 있는지 알고 싶습니다. 기본 NullLogger 인 정적 싱글 톤 로거는 어떻습니까? syslog-logging을 원한다면 런타임에 구현 객체를 변경하십시오.

그렇습니다. 로깅은 교차 문제이므로 SRP 를 위반 한 것입니다 .

올바른 방법은 로깅을 로거 클래스 (인터 셉션) 에 위임 하는 것입니다. 로그 작성은 SRP를 준수하는 것입니다.

좋은 예는 다음 링크를 참조하십시오. https://msdn.microsoft.com/en-us/library/dn178467%28v=pandp.30%29.aspx

다음은 간단한 예입니다 .

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

장점은 다음과 같습니다

• 로깅없이이를 테스트 할 수 있습니다-실제 단위 테스트
• 심지어 런타임에서도 쉽게 로그 온 / 오프를 토글 할 수 있습니다
• TenantStore 파일을 변경하지 않고도 다른 형태의 로깅 대신 로깅을 대체 할 수 있습니다.

SRP를 너무 진지하게 받아들이고 있다고 말할 수 있습니다. 로깅이 SRP의 유일한 "위반"이 될 정도로 코드가 깔끔하다면 다른 모든 프로그래머의 99 % 이상을 수행하는 것입니다.

SRP의 요점은 다른 일을하는 코드가 모두 혼합 된 끔찍한 스파게티 코드를 피하는 것입니다. 로깅과 기능 코드를 혼합해도 알람 벨이 울리지 않습니다.

아니요, SRP 위반이 아닙니다.

로그로 보내는 메시지는 주변 코드와 같은 이유로 변경되어야합니다.

SRP를 위반하는 것은 코드에 직접 로깅하기 위해 특정 라이브러리를 사용하고 있습니다. 로깅 방법을 변경하기로 결정한 경우 SRP는 비즈니스 코드에 영향을 미치지 않아야한다고 명시합니다.

어떤 종류의 개요 Logger는 구현 코드에 액세스 할 수 있어야하며 구현시해야 할 말은 "이 메시지를 로그에 보내기"뿐입니다. 정확한 로깅 방법 (타임 스탬프조차도)을 결정하는 것은 구현의 책임이 아닙니다.

그런 다음 구현시 메시지를 보내는 로거가인지 여부도 알 수 없습니다 NullLogger.

그렇습니다.

나는 너무 빨리 크로스 커팅 문제로 로깅을 솔질하지 않을 것 입니다. 구현 코드에서 발생하는 특정 이벤트를 추적하기 위해 로그를 내보내는 것은 구현 코드에 속합니다.

교차 절단 문제인 OTOH는 실행 추적입니다 . 로깅은 각 방법마다 들어오고 나갑니다. 이 작업을 수행하는 것이 가장 좋습니다.

로깅은 종종 교차 문제로 간주되므로 구현에서 로깅을 분리하기 위해 AOP를 사용하는 것이 좋습니다.

언어에 따라 인터셉터 또는 일부 AOP 프레임 워크 (예 : Java의 AspectJ)를 사용하여이를 수행합니다.

문제는 이것이 실제로 번거로운 가치가 있는지입니다. 이러한 분리는 프로젝트의 복잡성을 증가시키면서 거의 이점을 제공하지 않습니다.

잘 들립니다. 상당히 표준적인 로깅 데코레이터를 설명하고 있습니다. 당신은 :

구성 요소 L (시스템의 로깅 구성 요소)

여기에는 하나의 책임이 있습니다 : 정보를 전달하는 로깅.

컴포넌트 A는 I를 구현

인터페이스 I의 구현 제공 (I가 SRP를 올바르게 준수한다고 가정)은 하나의 책임이 있습니다.

이것은 중요한 부분입니다.

컴포넌트 D는 I를 구현하고 A를 장식 / 사용하며 로깅에 L을 사용합니다.

그렇게 말하면 복잡하게 들리지만 다음과 같이보십시오. 컴포넌트 D는 한 가지를 수행합니다. A와 L을 함께 가져옵니다.

• 구성 요소 D는 기록하지 않습니다. L에게 위임
• 컴포넌트 D는 I 자체를 구현하지 않습니다. 그것을 A에게 위임

만 구성 요소 D가 가지고있는 책임은 모르겠 사용하는 경우 L 통지되었는지 확인하는 것입니다. A와 L의 구현은 모두 다른 곳에 있습니다. 이것은 완전히 SRP를 준수하며 OCP의 깔끔한 예이며 데코레이터의 일반적인 사용입니다.

중요한주의해야 할 점은 : D는 로깅 구성 요소 L을 사용하는 경우, 당신이 변경할 수있는 방법을 사용해야한다 방법 당신에게있는 거 로깅을. 이를 수행하는 가장 간단한 방법은 L로 구현 된 인터페이스 IL을 갖는 것입니다.

• 구성 요소 D는 IL을 사용하여 기록합니다. L의 인스턴스가 제공됩니다
• 구성 요소 D는 I를 사용하여 기능을 제공합니다. A의 인스턴스가 제공됩니다
• 성분 B는 I를 사용합니다. D의 인스턴스가 제공됩니다

그렇게하면 다른 것에 직접 의존하는 것이 없으므로 쉽게 교체 할 수 있습니다. 이를 통해 변경에 쉽게 적응하고 시스템의 일부를 조롱하여 단위 테스트를 수행 할 수 있습니다.

물론 교차 절단 문제가 있으므로 SRP를 위반합니다. 그러나 조치를 실행하여 로깅을 작성하는 클래스를 작성할 수 있습니다.

예:

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