SRP를 구현하는 실용적인 방법은 무엇입니까?

클래스가 단일 책임 원칙을 위반하는지 확인하기 위해 사람들이 실제로 사용하는 기술은 무엇입니까?

나는 수업이 바뀌어야 할 이유가 하나 밖에 없다는 것을 알고 있지만, 그 문장에는 실제로 그것을 구현할 실질적인 방법이 부족하다.

내가 찾은 유일한 방법은 ".........해야합니다 ......... 자체" 문장을 사용하는 것입니다. 여기서 첫 번째 공백은 클래스 이름이고 나중에 공백은 메서드 (책임) 이름입니다.

그러나 때로는 책임이 실제로 SRP를 위반하는지 파악하기가 어렵습니다.

SRP를 확인하는 방법이 더 있습니까?

노트 :

문제는 SRP의 의미에 대한 것이 아니라 SRP를 확인하고 구현하기위한 실용적인 방법론 또는 일련의 단계입니다.

최신 정보

SRP를 분명히 위반하는 샘플 클래스를 추가했습니다. 사람들이 단일 책임 원칙에 접근하는 방법을 설명하기 위해 예제로 사용할 수 있다면 좋을 것입니다.

예는 여기에서 입니다.

SRP는 확실하지 않은 용어로 클래스가 변경해야 할 이유가 하나만 있어야한다고 언급합니다.

질문에서 "report"클래스를 해체 할 때 세 가지 방법이 있습니다.

• printReport
• getReportData
• formatReport

Report모든 방법에서 중복 이 사용되는 것을 무시하면 이것이 왜 SRP를 위반하는지 쉽게 알 수 있습니다.

• "인쇄"라는 용어는 일종의 UI 또는 실제 프린터를 의미합니다. 따라서이 클래스에는 일정량의 UI 또는 프리젠 테이션 로직이 포함됩니다. UI 요구 사항을 변경하려면 Report클래스를 변경해야합니다 .

• "데이터"라는 용어는 어떤 종류의 데이터 구조를 의미하지만 실제로 무엇을 지정하지는 않습니다 (XML? JSON? CSV?). 그럼에도 불구하고 보고서의 "내용"이 변경되면이 방법도 변경됩니다. 데이터베이스 또는 도메인에 연결되어 있습니다.

• formatReport는 일반적으로 메서드의 끔찍한 이름이지만 UI와 관련이 있으며 UI와는 다른 측면이 있다고 생각 printReport합니다. 따라서 관련이없는 또 다른 이유가 있습니다.

따라서이 클래스는 데이터베이스, 스크린 / 프린터 장치 및 로그 나 파일 출력 등을위한 내부 형식 지정 논리 와 결합 될 수 있습니다 . 한 클래스에 세 가지 함수를 모두 사용하면 종속성 수를 곱하고 종속성 또는 요구 사항 변경으로 인해이 클래스 (또는 그에 의존하는 다른 클래스)가 중단 될 확률이 3 배가됩니다.

여기서 문제의 일부는 특히 가시적 인 예를 골랐다는 것입니다. 한 가지만Report 수행하더라도. 라는 클래스가 없어야합니다 . 왜냐하면 ... 어떤 보고서입니까? 다른 데이터와 다른 요구 사항에 따라 모든 "보고"가 완전히 다른 짐승이 아닌가? 그리고 스크린이나 인쇄용으로 이미 포맷 된 보고서가 아닌가 ?

그러나 과거를 살펴보고 가상의 구체적인 이름을 만들어 봅시다. IncomeStatement하나는 매우 일반적인 보고서입니다. 적절한 "SRP"아키텍처는 세 가지 유형이 있습니다.

• IncomeStatement- 형식이 지정된 보고서에 나타나는 정보 를 포함 및 / 또는 계산 하는 도메인 및 / 또는 모델 클래스 .

• IncomeStatementPrinter, 아마도 같은 표준 인터페이스를 구현할 것입니다 IPrintable<T>. 하나의 주요 방법 Print(IncomeStatement)과 인쇄 별 설정 구성을위한 다른 방법 또는 속성이 있습니다.

• IncomeStatementRenderer화면 렌더링을 처리하며 프린터 클래스와 매우 유사합니다.

• 또한 IncomeStatementExporter/ 와 같은 기능별 클래스를 추가 할 수도 있습니다 IExportable<TReport, TFormat>.

이것은 제네릭 및 IoC 컨테이너를 도입하여 현대 언어에서 훨씬 더 쉬워졌습니다. 대부분의 응용 프로그램 코드는 특정 IncomeStatementPrinter클래스 에 의존 할 필요가 없으며 모든 종류의 인쇄 가능한 보고서를 사용 IPrintable<T>하여 작동 할 수 있습니다.이 방법을 사용 하면 기본 클래스 의 모든 이점을 방법과 함께 제공하며 일반적인 SRP 위반은 없습니다 . 실제 구현은 IoC 컨테이너 등록에서 한 번만 선언하면됩니다.Reportprint

일부 사람들은 위의 디자인에 직면했을 때 다음과 같이 응답합니다. "이것은 절차 코드처럼 보이며 OOP의 요점은 데이터와 동작의 분리로부터 우리를 떠나는 것입니다!" 내가 말하는 것 : wrong .

는 IncomeStatement것입니다 하지 그냥 "데이터", 및 상기 실수는 그들이에 관련이없는 기능을 모든 종류의 방해 시작 이후 이러한 "투명"클래스를 생성하여 뭔가 잘못을하고있다 느낌 OOP의 사람들의 많은 원인이 무엇 인 IncomeStatement것을, (물론 게으름). 이 클래스는 데이터로 시작될 수 있지만 시간이 지남에 따라 더 많은 모델이 될 것 입니다.

예를 들어 실제 손익 계산서에는 총 수익 , 총 비용 및 순이익 라인이 있습니다. 적절하게 설계된 금융 시스템은 거래 데이터가 아니기 때문에 이러한 데이터를 저장 하지 않을 가능성이 높습니다 . 실제로 새로운 거래 데이터의 추가에 따라 변경됩니다. 그러나 이러한 선의 계산 은 보고서 인쇄, 렌더링 또는 내보내기에 관계없이 항상 동일합니다. 당신의 그래서 IncomeStatement클래스의 형태로 그것에 행동의 공정한 금액을해야 할 것입니다 getTotalRevenues(), getTotalExpenses()및 getNetIncome()방법, 그리고 아마도 몇 가지 다른 사람. 실제로 "하지"않는 것처럼 보이지만 자체 동작이있는 진정한 OOP 스타일의 객체입니다.

그러나 format및 print방법은 정보 자체와 관련이 없습니다. 실제로, 이러한 방법의 여러 가지 구현 , 예를 들어 경영진에 대한 자세한 설명 및 주주에 대한 자세한 설명이 필요하지는 않습니다. 이러한 독립 함수를 다른 클래스로 분리하면 모든 크기의 단일 print(bool includeDetails, bool includeSubtotals, bool includeTotals, int columnWidth, CompanyLetterhead letterhead, ...)메소드에 대한 부담없이 런타임에 다른 구현을 선택할 수 있습니다 . 왝!

위의 대규모 매개 변수화 된 메소드가 잘못되는 부분과 별도의 구현이 올바른 곳을 알 수 있기를 바랍니다. 단일 개체의 경우 인쇄 논리에 새 주름을 추가 할 때마다 도메인 모델을 변경해야합니다 ( 재무 팀은 페이지 번호를 원하지만 내부 보고서에서만이를 추가 할 수 있습니까? ). 하나 또는 두 개의 위성 클래스에 구성 속성을 추가하기 만하면됩니다.

SRP를 올바르게 구현하는 것은 종속성 관리에 관한 것입니다 . 요컨대, 클래스가 이미 유용한 것을 수행하고 UI, 프린터, 네트워크, 파일 등과 같은 새로운 종속성을 도입하는 다른 메소드를 추가하는 것을 고려하고 있다면 안됩니다 . 대신 이 기능을 새 클래스 에 추가 할 수있는 방법과이 새 클래스를 전체 아키텍처에 적합하게 만드는 방법을 고려하십시오 (종속성 주입을 중심으로 디자인 할 때 매우 쉽습니다). 이것이 일반적인 원칙 / 과정입니다.

참고 사항 : Robert와 마찬가지로 SRP 호환 클래스에는 하나 또는 두 개의 상태 변수 만 있어야한다는 개념을 특허 적으로 거부합니다. 이러한 얇은 래퍼는 실제로 유용한 기능을 거의 기대하지 않습니다. 따라서 이것으로 배 밖으로 가지 마십시오.

SRP를 확인하는 방법은 클래스의 모든 방법 (책임)을 확인하고 다음 질문을하는 것입니다.

"이 기능을 구현하는 방식을 바꿔야합니까?"

어떤 종류의 구성이나 조건에 따라 다른 방법으로 구현 해야하는 기능을 찾으면이 책임을 처리하기 위해 추가 클래스가 필요하다는 것을 알고 있습니다.

Object Calisthenics의 규칙 8에서 인용 한 내용은 다음과 같습니다 .

대부분의 클래스는 단순히 단일 상태 변수를 처리해야하지만 두 개가 필요한 클래스도 있습니다. 클래스에 새 인스턴스 변수를 추가하면 해당 클래스의 응집력이 즉시 감소합니다. 일반적으로 이러한 규칙에 따라 프로그래밍하는 동안 단일 인스턴스 변수의 상태를 유지하는 클래스와 별도의 두 변수를 조정하는 클래스의 두 종류가 있습니다. 일반적으로 두 가지 책임을 혼합하지 마십시오

이 (어떤 이상 주의적) 견해를 감안할 때, 하나 또는 두 개의 상태 변수를 포함하는 클래스는 SRP를 위반하지 않을 것이라고 말할 수 있습니다. 또한 두 개 이상의 상태 변수를 포함하는 클래스 는 SRP를 위반할 수 있습니다 .

하나의 가능한 구현 (Java). 나는 반환 유형으로 자유를 얻었지만 무엇보다도 질문에 대한 답변이라고 생각합니다. TBH 나는 더 나은 이름이 순서가 있지만 보고서 클래스의 인터페이스가 그렇게 나쁘지 않다고 생각합니다. 나는 간결한 진술과 진술을 생략했다.

편집 : 또한 클래스는 불변입니다. 일단 생성되면 아무것도 변경할 수 없습니다. setFormatter () 및 setPrinter ()를 추가하면 문제가 발생하지 않습니다. IMHO의 핵심은 인스턴스화 후 원시 데이터를 변경하지 않는 것입니다.

public class Report
{
    private ReportData data;
    private ReportDataDao dao;
    private ReportFormatter formatter;
    private ReportPrinter printer;


    /*
     *  Parameterized constructor for depndency injection, 
     *  there are better ways but this is explicit.
     */
    public Report(ReportDataDao dao, 
        ReportFormatter formatter, ReportPrinter printer)
    {
        super();
        this.dao = dao;
        this.formatter = formatter;
        this.printer = printer;
    }

    /*
     * Delegates to the injected printer.
     */
    public void printReport()
    {
        printer.print(formatReport());
    }


    /*
     * Lazy loading of data, delegates to the dao 
     * for the meat of the call.
     */
    public ReportData getReportData()
    {
        if (reportData == null)
        {
            reportData = dao.loadData();
        }
        return reportData;
    }

    /*
     * Delegate to the formatter for formatting 
     * (notice a pattern here).
     */
    public ReportData formatReport()
    {
        formatter.format(getReportData());
    }
}

귀하의 예에서 SRP가 위반되고 있음이 확실하지 않습니다. 보고서가 비교적 단순하다면 보고서 자체를 형식화하고 인쇄 할 수 있어야합니다.

class Report {
  void format() {
     text = text.trim();
  }

  void print() {
     new Printer().write(text);
  }
}

메소드는 너무 단순하여 클래스 ReportFormatter나 ReportPrinter클래스 를 갖는 것이 이치에 맞지 않습니다 . 인터페이스의 유일한 눈부신 문제는 getReportData값이 아닌 객체에 대해 묻지 말고 위반하기 때문입니다.

반면에 방법이 매우 복잡하거나 형식을 지정하거나 인쇄하는 방법이 여러 가지 인 Report경우 책임을 위임하는 것이 좋습니다 (더 테스트 가능).

class Report {
  void format(ReportFormatter formatter) {
     text = formatter.format(text);
  }

  void print(ReportPrinter printer) {
     printer.write(text);
  }
}

SRP는 철학적 개념이 아닌 설계 원칙이므로 실제 작업중인 코드를 기반으로합니다. 의미 적으로 클래스를 원하는만큼의 책임으로 나누거나 그룹화 할 수 있습니다. 그러나 실용적인 원칙으로 SRP는 수정해야 할 코드를 찾는 데 도움이 됩니다. SRP를 위반하는 징후는 다음과 같습니다.

• 수업은 너무 커서 스크롤하거나 올바른 방법을 찾는 데 시간을 낭비합니다.
• 수업은 매우 작으며 수많은 수업 사이에서 뛰어 내리거나 올바른 수업을 찾는 데 시간을 낭비합니다.
• 변경해야 할 때 많은 클래스에 영향을 미치므로 추적하기가 어렵습니다.
• 변경해야 할 때 어떤 클래스를 변경해야하는지 명확하지 않습니다.

이름을 개선하고, 유사한 코드를 그룹화하고, 중복을 제거하고, 계층화 된 디자인을 사용하고, 필요에 따라 클래스를 분할 / 결합함으로써 리팩토링을 통해 이러한 문제를 해결할 수 있습니다. SRP를 배우는 가장 좋은 방법은 코드베이스에 들어가 고통을 리팩터링하는 것입니다.

단일 책임 원칙 은 응집 개념과 밀접한 관련이 있습니다. 매우 응집력있는 클래스를 가지려면 클래스의 인스턴스 변수와 해당 메소드 사이에 상호 의존성이 있어야합니다. 즉, 각 메소드는 가능한 한 많은 인스턴스 변수를 조작해야합니다. 메소드가 사용하는 변수가 많을수록 클래스에 대한 응집력이 커집니다. 최대 응집력은 일반적으로 달성 할 수 없습니다.

또한 SRP를 잘 적용하기 위해서는 비즈니스 논리 영역을 잘 이해해야합니다. 각 추상화가 무엇을해야하는지 알기 위해. 계층 구조는 각 계층이 특정 작업을 수행하도록하여 SRP 와도 관련이 있습니다 (데이터 소스 계층은 데이터 등을 제공해야 함).

메소드가 모든 변수를 사용하지 않더라도 응집력으로 돌아와서 결합해야합니다.

public class MyClass {
    private Type1 var1;
    private Type2 var2;
    private Type3 var3;

    public Type3 method1() {
        //use var1 and var3
    }  

    public void method2() {
        //use var1 and var2
    }

    public Type1 method3() {
        //use var2 and var3
    }
}

코드 아래와 같은 것은 없어야합니다. 여기서 인스턴스 변수의 일부는 메소드의 일부에 사용되고 변수의 다른 일부는 메소드의 다른 부분에 사용됩니다 (여기서는 두 개의 클래스가 있어야합니다) 변수의 각 부분).

public class MyClass {
    private Type1 var1;
    private Type2 var2;
    private Type3 var3;
    private TypeA varA;
    private TypeB varB;

    public Type3 method1() {
        //use var1 and var3
    }  

    public void method2() {
        //use var1 and var2
    }

    public TypeA methodA() {
        //use varA and varB
    }

    public TypeA methodB() {
        //use varA
    }
}