명령 체인이 F(&O) 커스터마이징의 기본 패턴이 되었습니다. 오버레이 접근 방식은 지속할 수 없었기 때문입니다. 매번 One Version 업데이트가 무언가를 깨뜨리고 파트너들은 설계상 앞으로 호환되어야 할 커스터마이징을 수리하기 위해 업그레이드 예산을 썼습니다. CoC는 확장 프로그램이 next()을 사용하여 기본 메서드를 래핑하고 전적으로 오버레이 춤을 건너뛸 수 있게 합니다.
작동 원리를 읽는 데 한 분이 걸립니다. 생산 중에 자주 발생하여 기록해야 할 세 가지 오류 모드가 나타납니다.
함정 1: next()를 증가시킬 때 깜빡함
CoC에 새로운 팀은 종종 다음과 같은 검증 확장을 작성합니다:
[ExtensionOf(tableStr(SalesTable))]
final class SalesTableExt_Extension
{
public boolean validateWrite()
{
if (this.CustomCheck == NoYes::No)
{
return checkFailed("Custom check failed");
}
return true;
}
}
오류: 없음next validateWrite() 호출. 기본 메서드는 실행되지 않으므로 모든 재고 검증이 조용히 사라짐. 오직 커스텀-체크 경로만 실행되는 단위 테스트는 통과됨. 빠진 기본 검증은 기본이 거부했을 테 데이터가 생산 환경으로 통과하면 나타나지 않음.
로직을 추가하는 것이 아니라 대체하는 것이 목적이라면, 먼저 next()를 호출하고 결과를 결합하라:
public boolean validateWrite()
{
boolean ret = next validateWrite();
if (ret && this.CustomCheck == NoYes::No)
{
ret = checkFailed("Custom check failed");
}
return ret;
}
next()을 건너뛰는 것은 때때로 합법적일 수 있지만, 의도적이어야 하며, 주석을 달고 검토되어야 합니다. 의도치 않은 건너뛰기는 침묵하는 데이터 무결성 버그가 살아있는 곳입니다.
함정 2: 잘못된 생애주기 핸들 선택
FormDataSource.init()은 기록이 로드되기 전에 실행됩니다. 익스텐션 코드가 읽는 것은this.cursor() 또는 기록 컨텍스트를 가정하면 예외가 발생하거나 예측 불가능하게 동작합니다. 동적 필터를 배포하는 팀들은 로직을 init()에 넣곤 하는데, 그 이유는 그것이 첫 번째 훅(hook)을 보는 것부터이기 때문입니다. 그런 다음 사용자가 비어 있는 데이터셋을 가진 경우에 폼을 열 때 처음으로 크래시가 발생합니다.
폼 수준의 생명주기 훅(lifecycle hook)은 각각 목적이 있습니다.
-
init()- 폼 수준 설정, 아직 데이터 없음 -
executeQuery()- 쿼리가 구축된 후, fetch 전 -
active()- 데이터 소스에 기록이 활성화된 후 - 이벤트 전/후 처리기(
executeQuery) - 기본을 재정의하지 않고 쿼리를 변형하는 가장 깨끗한 방법
파라미터 테이블에서 동적 필터링을 위해, executeQuery의 이벤트 전 처리기는 이벤트 인수를 통해 사용할 수 있는 데이터 컨텍스트를 이용해 쿼리의 범위를 수정할 수 있습니다. crash 없이, 기본 메서드 재정의 없이, 무뎌진 하위 연결 없이.
3번 함정: private 또는 protected 멤버에 접근하려고 함
CoC 확장은 기본 클래스의 private 또는 protected 멤버에 접근할 수 없습니다. 오버레이 시대의 F&O로 이전하는 개발자들은 첫 번째로 이 문제를 마주합니다:
[ExtensionOf(classStr(SalesLineType))]
final class SalesLineTypeExt_Extension
{
public boolean checkPrice()
{
// Compile error: _commonPricing is protected
return this._commonPricing.checkMyThing();
}
}
Microsoft의 확장 프레임워크 문서에는 네 가지 옵션이 설명되어 있습니다.
- 호킹 가능한 기본 메서드 - 개인적인 행동이 공개 메서드를 통해 노출될 경우, 그 메서드를 호출하세요.
- 형제 클래스 접근 - 가끔 공개 클래스가 필요한 것을 충분히 노출할 수 있습니다.
- 데이터를 인수를 통해 노출하는 메서드의 이벤트 핸들러 - 가장 깨끗한 경로입니다.
- LCS 이슈 검색을 통해 접근 요청 - Microsoft는 여러 버전 릴리스에 따른 파트너 요청에 응해 많은 회원을 개설했습니다.
반성을 찾으려는 것은 잘못된 답변입니다. 다음 컴파일이 멤버 레이아웃을 변경할 때까지는 작동하지만, 다시 오버레이 수준의 취약성으로 돌아옵니다.
침묵하는 확장을 디버깅합니다
가장 짜증 나는 CoC 실패는 컴파일되고 배포되지만 실행 시 아무것도 하지 않는 확장입니다. 작동하는 F&O 코드베이스의 리뷰에서 나타나는 근본 원인:
-
[ExtensionOf]속성이 잘못된 대상을 가리킨다 -formStr()/tableStr()/classStr()에 타이포가 있습니다. - 확장 클래스는
final- CoC에 필요합니다. - 메서드 서명이 정확히 일치하지 않습니다 - 매개변수 유형 불일치는 조용히 건너뜁니다.
- 확장을 포함하는 모델이 대상 환경의 모델 목록에 없습니다.
첫 번째 진단 단계: 메서드 맨 위에 info("hit")를 드롭하고, 재컴파일하고, 시나리오를 실행하고, Infolog를 확인합니다. 아무것도 나타나지 않으면 하나 이상의 위 사항이 잘못되었습니다.
코드 리뷰는 보험입니다
건강한 F & O 코드베이스를 사용하는 팀은 CoC 확장에 대해 PR 시간 체크리스트를 사용합니다: next()가 올바르게 호출되었는지, 적절한 생명주기 훅이 선택되었는지, 개인 멤버 접근 시도가 없는지, SysTest를 통해 단위 테스트 커버리지가 있는지 확인합니다. PR당 15분은 한 버전 업데이트가 주말 장애로 변하지 않도록 보험 정책처럼 작동합니다.