이벤트 중심 프로그래밍 : 언제 가치가 있습니까?

이 질문의 제목이 이벤트 기반 프로그래밍 을 언제 사용해야합니까?와 거의 동일하다는 것을 알고 있습니다. 그러나 위의 질문에 대한 답변은 내가 직면 한 특정 사례에서 이벤트를 사용 해야하는지 여부를 결정하는 데 도움이되지 않았습니다.

작은 응용 프로그램을 개발 중입니다. 그것은 간단한 응용 프로그램이며, 대부분의 기능은 기본 CRUD입니다.

특정 이벤트 (특정 데이터를 수정할 때)가 발생하면 응용 프로그램은 해당 데이터의 로컬 사본을 파일에 작성해야합니다. 이것을 구현하는 가장 좋은 방법이 무엇인지 잘 모르겠습니다. 저 할 수 있어요:

• 데이터가 수정되면 이벤트를 발생시키고 해당 이벤트에 응답 (파일 생성)을 바인딩합니다. 또는 관찰자 패턴을 구현하십시오. 그것은 불필요한 복잡성처럼 보입니다.
• 데이터를 수정하는 코드에서 직접 파일 생성 코드를 호출하십시오. 훨씬 간단하지만 의존성이 이런 식이어야한다는 것은 잘못된 것 같습니다. 즉, 앱의 핵심 기능 (데이터를 수정하는 코드)이 여분의 특권 (백업 파일을 생성하는 코드)에 결합되어있는 것은 잘못된 것 같습니다. 그러나 나는이 응용 프로그램이 그 결합이 문제를 일으키는 지점으로 진화하지 않을 것이라는 것을 알고 있습니다.

이 경우 가장 좋은 방법은 무엇입니까?

KISS 원칙을 따르십시오 : 단순성, 멍청함 또는 YAGNI 원칙 : 필요하지 않습니다.

다음과 같은 코드를 작성할 수 있습니다.

void updateSpecialData() {
    // do the update.
    backupData();
}

또는 다음과 같은 코드를 작성할 수 있습니다.

void updateSpecialData() {
     // do the update.
     emit SpecialDataUpdated();
}

void SpecialDataUpdatedHandler() {
     backupData();
}

void configureEventHandlers() {
     connect(SpecialDataUpdate, SpecialDataUpdatedHandler);
}

다른 방법을 강구해야 할 이유가 없다면 간단한 경로를 따르십시오. 이벤트 처리와 같은 기술은 강력하지만 코드의 복잡성을 증가시킵니다. 작동하려면 더 많은 코드가 필요하며 코드에서 발생하는 일을 따르기가 더 어려워집니다.

이벤트는 올바른 상황에서 매우 중요합니다 (이벤트없이 UI 프로그래밍을 시도한다고 상상해보십시오!). 대신 KISS 또는 YAGNI를 사용할 수있을 때는 사용하지 마십시오.

간단한 데이터에 대해 설명하는 예제는 수정이 일부 효과를 유발하는 관찰자 디자인 패턴으로 완벽하게 구현할 수 있습니다 .

• 전체 이벤트 중심 코드보다 구현 및 유지 관리가 더 간단합니다.
• 대상과 관찰자 사이의 결합은 추상적 일 수 있으며, 이는 관심의 분리를 용이하게한다.
• 일대 다 관계에 이상적입니다 (피험자는 하나 또는 많은 관찰자를 가짐).

이벤트 중심 접근 방식은 많은 다른 상호 작용이 발생하거나 다 대다 상황에서 연쇄 반응이 예상되는 경우 (예 : 피험자가 관찰자에게 알리기 위해 경우에 따라 과목 또는 기타 과목)

당신이 말했듯이, 이벤트는 클래스 간의 연결을 줄이는 훌륭한 도구입니다. 따라서 내장 된 이벤트 지원없이 일부 언어로 추가 코드를 작성할 수 있지만 큰 그림의 복잡성을 줄입니다.

이벤트는 OO에서 가장 중요한 도구 중 하나입니다 (Alan Kay에 따르면-Objects는 메시지를주고 받음으로써 통신합니다 ). 이벤트 지원 기능이 내장 된 언어를 사용하거나 기능을 일급 시민으로 취급하는 경우,이를 사용하는 것은 쉬운 일이 아닙니다.

내장 된 지원이없는 언어에서도 Observer 패턴과 같은 보일러 플레이트의 양은 매우 적습니다. 상용구를 최소화하기 위해 모든 응용 프로그램에서 사용할 수있는 적절한 일반 이벤트 라이브러리를 찾을 수 있습니다. 일반 이벤트 수집기 또는 이벤트 중재자는 거의 모든 종류의 응용 프로그램에 유용합니다.

작은 응용 프로그램에서 가치가 있습니까? 나는 확실히 그렇다고 말할 것 입니다.

• 클래스를 서로 분리 된 상태로 유지하면 클래스 종속성 그래프가 깨끗하게 유지됩니다.
• 구체적인 종속성이없는 클래스는 테스트의 다른 클래스를 고려하지 않고 개별적으로 테스트 할 수 있습니다.
• 구체적인 종속성이없는 클래스는 완전한 적용을 위해 더 적은 단위 테스트가 필요합니다.

"아, 그러나 아주 작은 응용 프로그램 일뿐" 이라면 실제로 그렇게 중요하지는 않습니다 .

• 작은 응용 프로그램은 때때로 나중에 더 큰 응용 프로그램과 결합되기도합니다.
• 소규모 응용 프로그램에는 나중에 다른 응용 프로그램에서 다시 사용해야하는 일부 논리 또는 구성 요소가 포함될 수 있습니다.
• 소규모 애플리케이션에 대한 요구 사항이 변경되어 리팩터링이 필요하므로 기존 코드를 분리 할 때 더 쉽습니다.
• 나중에 추가 기능을 추가하여 기존 코드를 확장해야 할 필요성을 나타내며 기존 코드가 이미 분리 된 경우에도 훨씬 쉽습니다.
• 느슨하게 결합 된 코드는 일반적으로 밀접하게 결합 된 코드보다 작성하는 데 시간이 오래 걸리지 않습니다. 단단하게 결합 된 코드는 느슨하게 결합 된 코드보다 리팩토링 및 테스트하는 데 훨씬 오래 걸립니다.

전반적으로 응용 프로그램의 크기는 클래스를 느슨하게 결합 시킬지 여부를 결정하는 요소가되어서는 안됩니다. SOLID 원칙은 대규모 응용 프로그램만을위한 것이 아니라 모든 규모의 소프트웨어 및 코드베이스에 적용 할 수 있습니다.

실제로 느슨하게 결합 된 클래스를 개별적으로 테스트 할 때 절약되는 시간은 해당 클래스를 분리하는 데 소요되는 추가 시간과 균형을 맞 춥니 다.

옵저버 패턴은 Wikipedia 기사 (또는 GOF 서적)가 설명하는 것보다 훨씬 작은 방식으로 구현 될 수 있으며 , 프로그래밍 언어는 "콜백"또는 "위임"과 같은 것을 지원한다고 가정합니다. 콜백 메소드를 CRUD 코드 (일반적인 "파일에 기록"메소드이거나 비어있는 메소드)에 전달하십시오. "이벤트 발생"대신 해당 콜백을 호출하십시오.

결과 코드는 파일 생성 코드를 직접 호출하는 것보다 최소한의 복잡성을 갖지만 관련이없는 구성 요소의 긴밀한 연결 단점이 없습니다.

그러면 "YAGNI"의 디커플링을 희생하지 않고도 "두 세계 최고"를 얻을 수 있습니다.