후크는 언제 올바른 디자인 선택입니까?

ActiveRecord 콜백 사용이 만연하고 비좁은 대형 Rails 앱에서 작업했습니다. 레코드를 저장하면 종종 예기치 않은 부작용이 발생하여 시스템에 대해 추론하기가 어려웠습니다.

동시에, 후크가 상속의 일부로 잘 사용되는 후크를 보았습니다 (예 : 템플릿 메소드를 사용하는 서브 클래스가 서브 클래스가 부모의 내부에 대해 알 필요없이 특수 행동을 추가 할 수 있도록 허용 함). (예 : 활성화 될 때 후크를 실행하는 emacs 모드, 사용자가 해당 모드 주위에 사용자 정의 동작을 추가 할 수 있도록 허용)

Rails 앱과 Lisp 인터프리터는 매우 다른 시스템이라는 것을 알고 있지만, 훅이 직면 한 문제에 적합한 디자인 선택인지 결정할 때 사람들이 잘 알고있는 기준이 있는지 궁금합니다.

나에게 돋보이는 주제는 예측 가능성입니다. 후크를 잘못 사용 하면 먼 거리 에서 놀라운 동작이 발생하고 놀라운 동작이 발생하는 반면, 잘 사용하면 긴밀한 연결없이 예측 가능한 프레임 워크가 생성 될 수 있습니다.

나는 아직도 프로그래밍 경력을 쌓은 지 몇 년이 지났기 때문에 많은 측면에서 나 자신을 멍청한 것으로 생각하며 사람들 이이 주제에 대해 상당한 양의 생각을했다고 의심합니다. 이 결정을 안내 할 수있는 몇 가지 지침은 무엇입니까?

후크는 제어를 후크의 수신자로 전송하여 소비자의 추상화 구현 세부 사항을 분리하려는 경우 적합한 설계 선택입니다.

익명 브로드 캐스트 (이벤트 또는 익명 콜백과 같은) 또는 유형이 지정된 추상화 (인터페이스 또는 상위 클래스)를 사용하여이를 수행 할 수 있습니다.

다음과 같은 경우 익명 브로드 캐스트를 사용해야합니다.

• 후크의 호출은 선택 사항입니다
• 발신자는 누가 후크를 받는지 신경 쓰지 않습니다.
• 수신기의 실행 순서는 관련이 없습니다.
• 후크의 모든 구독자에게 오브젝트 상태를 브로드 캐스트하려고합니다.

다음과 같은 경우 유형이 지정된 추상화를 사용해야합니다.

• 후크를 호출하는 것은 필수입니다.
• 호출 객체는 후크의 수신자를 식별해야합니다.
• 수신자의 실행 순서는 객체와 관련이 있습니다.

브로드 캐스트 후크의 예는 KeyPressedEvent입니다. 이벤트를 발생시키는 클래스는 누가 이벤트를 수신하는지 상관하지 않으며 이벤트에 가입 한 모든 사람에게 키보드 상태를 브로드 캐스트합니다. 수신자의 실행 순서는 이벤트를 발생시키는 클래스의 객체 상태에 영향을 미치지 않습니다.

형식화 된 추상화 후크의 예는 언급 한 템플릿 방법입니다. 이 경우 부모 클래스는 템플릿 메서드에 대한 구현이 필요하고 수신자가 해당 메서드의 자식임을 알고 부모 클래스에 의해 정의 된 템플릿 메서드에 대한 특정 실행 순서를 갖습니다.

대부분의 언어와 대부분의 플랫폼은 다른 것으로 차려 입더라도 후크를 사용합니다. "이벤트", "메시지", "트리거", "시그널"또는 그 성격의 다른 용어에 대해들을 때마다 규칙에 대한 예외가있을 수 있지만 훅킹을 다루는 것일 수 있습니다. 이 토론의 문제.

플랫폼에서 제공하거나 성능상의 이유로 사용이 필요할 수 있으므로 사용하십시오. 후크를 사용하면 코드 복잡성이 줄어들고 비즈니스 요구 사항이 적용되며 CPU 사용이 줄어들어 배터리 및 하드웨어 수명이 연장됩니다. 코드에서 최상의 성능을 원할 때마다 사용해야합니다.

Rails에 대한 귀찮은 경험조차도 후크의 일반적인 사용 사례를 식별합니다. 비즈니스 규칙을 시행해야하며 후크는 비즈니스 규칙을 시행하는 데 거의 보편적으로 사용됩니다. 불행히도, 모든 규칙이 의미가있는 것은 아니며, 알 수 있듯이 개발자가 임의적 일 때 어려워지기 때문에 시스템 문서화가 코드 자체만큼이나 중요합니다.

일반적으로 후크는 성능 기능이기 때문에 후크를 사용하십시오. 코드는 다른 방법 (이벤트 폴링을 위해 바쁜 루프에서 대기하는 "폴링"이라고 함)보다 코드를보다 효율적으로 실행합니다. 그러나 적절한 문서를 사용하고 최신 상태로 유지하십시오. 후크는 거의 모든 언어에서 사용되며 왜 존재하는지 아는 것이 중요합니다.

나는 이전에 내 의견으로는 갈고리를 잘 사용하는 프로그램을 만들었다. 필자의 책에서 진정한 후크는 콜백 (구독자) 목록에 대한 호출 (게시)입니다. 강력하고 남용이 쉽습니다. 유스 케이스를 요청하는 가장 좋은 질문은 다음과 같습니다. 런타임에 동작을 활성화 또는 비활성화 하시겠습니까? 예를 들어, 사용자가 특정 이벤트에서 실행할 스크립트를 제공하거나 더 작은 플러그인으로 구성된 일반 프로그램을 만들도록 할 수 있습니다. 그런 다음 후크 호출이 적절합니다. 일반적으로 다른 옵션은 거의 없습니다.

그렇지 않다면, 당신은 좋은 아치를 가지고 떠나야합니다. 템플릿 메소드는 오버로드 된 함수와 잘 작동하므로이를 위해 런타임 로직이 필요하지 않습니다. 느슨한 연결을 강제한다고 생각하면 직접 호출하거나 연결하는 것 사이에 동일한 종속성 수준이 있으며 수신자는 어쨌든 계약을 작성해야합니다.

오버로드 된 함수 후킹으로 템플릿 메소드를 호출하는 사람도 있지만 위와 다른 점이 있습니다. 여기에는 정적 링크가있어 유지 관리의 악몽에 빠질 위험이 낮습니다.