콜 체인에서 여러 수준으로 만 사용되는 전달 매개 변수의 (안티) 패턴 이름이 있습니까?

일부 레거시 코드에서 전역 변수 사용에 대한 대안을 찾으려고했습니다. 그러나이 질문은 기술적 대안에 관한 것이 아니며 주로 용어 에 대해 우려하고 있습니다.

확실한 해결책은 전역을 사용하는 대신 매개 변수를 함수에 전달하는 것입니다. 이 레거시 코드베이스에서는 값이 사용될 지점과 매개 변수를 먼저받는 함수 사이에서 긴 콜 체인의 모든 함수를 변경해야합니다.

higherlevel(newParam)->level1(newParam)->level2(newParam)->level3(newParam)

경우는 newParam이전에 내 예제에서 전역 변수했지만, 대신 이전에 하드 코딩 값 수 있었다. 요점은 이제 newParam의 가치는에서 얻어 higherlevel()지고 "여행"해야한다는 것 level3()입니다.

이런 종류의 상황 / 패턴에 대한 이름 이 있는지 궁금해서 수정하지 않은 값을 "전달"하는 많은 함수에 매개 변수를 추가해야합니다.

적절한 용어를 사용하면 재 설계를위한 솔루션에 대한 더 많은 리소스를 찾고이 상황을 동료들에게 설명 할 수 있기를 바랍니다.

데이터 자체를 "트램프 데이터"라고 합니다. "코드 냄새"는 하나의 코드가 중개자를 통해 먼 거리에서 다른 코드와 통신하고 있음을 나타냅니다.

• 특히 콜 체인에서 코드의 강성을 증가시킵니다. 콜 체인에서 메소드를 리팩토링하는 방법에는 훨씬 더 제한적입니다.
• 데이터 / 방법 / 아키텍처에 대한 지식을 가장 신경 쓰지 않는 장소에 배포합니다. 방금 지나가는 데이터를 선언해야하고 선언에 새 가져 오기가 필요한 경우 네임 스페이스를 오염시킨 것입니다.

전역 변수를 제거하기위한 리팩토링은 어렵고, 부정기 데이터는이를 수행하는 한 가지 방법이며 종종 가장 저렴한 방법입니다. 비용이 듭니다.

나는 이것이 그 자체로 반 패턴이라고 생각하지 않습니다. 문제는 실제로 각 기능을 독립적 인 블랙 박스로 생각해야 할 때 함수를 체인으로 생각하고 있다는 것입니다 ( 참고 : 재귀 적 방법은이 조언에서 예외입니다).

예를 들어, 두 달력 날짜 사이의 일 수를 계산하여 함수를 만들어야한다고 가정 해 보겠습니다.

int daysBetween(Day a, Day b)

이를 위해 새 함수를 만듭니다.

int daysSinceEpoch(Day day)

그런 다음 첫 번째 기능은 간단하게됩니다.

int daysBetween(Day a, Day b)
{
    return daysSinceEpoch(b) - daysSinceEpoch(a);
}

이것에 대한 반 패턴은 없습니다. daysBetween 메소드의 매개 변수는 다른 메소드로 전달되고 메소드에서 달리 참조되지 않지만 해당 메소드가 수행해야하는 작업을 수행하는 데 여전히 필요합니다.

내가 추천하는 것은 각 기능을 살펴보고 몇 가지 질문으로 시작하는 것입니다.

• 이 기능이 명확하고 집중된 목표를 가지고 있습니까? 아니면 "일을하는"방법입니까? 일반적으로 함수의 이름이 여기에 도움이되며 이름으로 설명되지 않은 내용이 있으면 빨간색 플래그입니다.
• 너무 많은 매개 변수가 있습니까? 때로는 메소드가 많은 입력을 합법적으로 필요로 할 수 있지만 매개 변수가 너무 많으면 사용하거나 이해하기에 부담이됩니다.

메소드에 단일 목적으로 묶이지 않은 복잡한 코드를 살펴 보려면 먼저이를 풀어야합니다. 이것은 지루할 수 있습니다. 가장 쉬운 것부터 시작하여 별도의 방법으로 옮기고 일관된 것을 가질 때까지 반복하십시오.

매개 변수가 너무 많은 경우 Method to Object 리팩토링을 고려하십시오 .

BobDalgleish는 이 (반) 패턴을 " 트램프 데이터 " 라고 언급 했습니다 .

필자의 경험에 따르면 과도한 트램프 데이터의 가장 일반적인 원인은 객체 또는 데이터 구조에 실제로 캡슐화되어야하는 연결된 상태 변수가 많이 있기 때문입니다. 때로는 데이터를 올바르게 구성하기 위해 많은 개체를 중첩해야 할 수도 있습니다.

간단한 예를 들어, 같은 특성을 가진 사용자 정의 플레이어 캐릭터가있는 게임을 고려 playerName, playerEyeColor등등합니다. 물론 플레이어는 게임 맵에서 물리적 위치와 현재 및 최대 건강 수준 등과 같은 다양한 다른 속성을 가지고 있습니다.

이러한 게임의 첫 번째 반복에서는 이러한 모든 속성을 전역 변수로 만드는 것이 합리적 일 수 있습니다. 결국 플레이어는 하나 뿐이며 게임의 거의 모든 것이 플레이어와 관련이 있습니다. 따라서 전역 상태에는 다음과 같은 변수가 포함될 수 있습니다.

playerName = "Bob"
playerEyeColor = GREEN
playerXPosition = -8
playerYPosition = 136
playerHealth = 100
playerMaxHealth = 100

그러나 언젠가는 게임에 멀티 플레이어 모드를 추가하고 싶기 때문에이 디자인을 변경해야 할 수도 있습니다. 첫 번째 시도로 모든 변수를 로컬로 만들어 필요한 함수에 전달할 수 있습니다. 그러나 게임의 특정 액션에 다음과 같은 함수 호출 체인이 포함될 수 있습니다.

mainGameLoop()
 -> processInputEvent()
     -> doPlayerAction()
         -> movePlayer()
             -> checkCollision()
                 -> interactWithNPC()
                     -> interactWithShopkeeper()

...이 interactWithShopkeeper()기능은 상점 주인에게 플레이어 이름을 지정하므로 이제 모든 기능을 playerName통해 갑자기 부정기 데이터 를 전달해야 합니다. 물론 상점 주인이 파란 눈을 가진 플레이어가 순진하고 더 높은 가격을 책정한다고 생각 하면 전체 기능 체인 등 을 통과해야합니다 .playerEyeColor

적절한 솔루션이 경우, 이름을 캡슐화하는 플레이어 객체를 정의하는 물론, 눈 색깔, 위치, 건강과 플레이어 캐릭터의 다른 특성이다. 그렇게하면 플레이어와 관련된 모든 기능에 단일 객체를 전달하기 만하면됩니다.

또한, 위의 기능 중 일부는 자연스럽게 해당 플레이어 객체의 메소드로 만들어 질 수 있으며,이를 통해 플레이어의 속성에 자동으로 액세스 할 수 있습니다. 어쨌든 이것은 객체의 메소드를 호출하면 객체 인스턴스를 숨겨진 매개 변수로 메소드에 효과적으로 전달하기 때문에 구문상의 설탕 일뿐입니다. 그러나 올바르게 사용하면 코드가 더 명확하고 자연스럽게 보입니다.

물론, 전형적인 게임은 단순한 플레이어보다 훨씬 "전세계적인"상태를 가질 것입니다. 예를 들어, 게임이 진행되는지도와 플레이어가 아닌 캐릭터 목록,지도 위에 놓인 아이템 등이있을 것입니다. 주위의 모든 것을 tramp 객체로 전달할 수도 있지만 메소드 인수를 다시 혼란스럽게 만듭니다.

대신, 해결책은 오브젝트가 영구적 또는 임시 관계가있는 다른 오브젝트에 대한 참조를 저장하도록하는 것입니다. 따라서, 예를 들어, 플레이어 객체는 같은 방법 있도록 현재 수준 /지도에 대한 참조를 가질 것 "게임 세계"개체에 대한 참조를 저장해야합니다 아마 (아마 어떤 NPC가 너무 객체) player.moveTo(x, y)을 필요로하지 않는다 맵을 매개 변수로 명시 적으로 제공해야합니다.

마찬가지로 플레이어 캐릭터가 애완견을 따라 다니는 경우 개를 설명하는 모든 상태 변수를 자연스럽게 단일 개체로 그룹화하고 플레이어 개체에 개에 대한 참조를 제공합니다 (플레이어가 예를 들어, 개를 이름으로 부르고 그 반대의 경우도 있습니다 (개가 플레이어의 위치를 ​​알 수 있도록). 물론 플레이어와 개 개체를보다 일반적인 "actor"개체의 하위 클래스로 만들면지도에서 두 코드를 이동하는 데 동일한 코드를 재사용 할 수 있습니다.

추신. 게임을 예로 사용했지만 이러한 문제가 발생하는 다른 종류의 프로그램이 있습니다. 그러나 내 경험상 근본적인 문제는 항상 같은 경향이 있습니다. 하나 이상의 상호 연결된 객체로 함께 묶고 싶은 별도의 변수 (로컬 또는 글로벌 여부)가 있습니다. 함수에 침입하는 "트램프 데이터"가 수치 시뮬레이션에서 "글로벌"옵션 설정 또는 캐시 된 데이터베이스 쿼리 또는 상태 벡터로 구성되어 있는지 여부에 관계없이 솔루션은 데이터가 속하는 자연 컨텍스트 를 식별하고 이를 객체로 만드는 것입니다. (또는 선택한 언어에서 가장 가까운 것).

나는 이것에 대한 특정 이름을 알지 못하지만 설명하는 문제는 그러한 매개 변수의 범위에 대한 최상의 타협점을 찾는 문제 일 뿐이라고 언급 할 가치가 있다고 생각합니다.

• 전역 변수로서 프로그램이 특정 크기에 도달하면 범위가 너무 큽니다.

• 순전히 로컬 매개 변수로서, 호출 체인에 많은 반복 매개 변수 목록이 생길 때 범위가 너무 작을 수 있습니다.

• 트레이드 오프로서, 종종 하나 이상의 클래스에서 이러한 매개 변수를 멤버 변수로 만들 수 있습니다. 이것이 바로 적절한 클래스 디자인 이라고하는 것입니다 .

나는 당신이 묘사하는 패턴이 정확히 의존성 주입 이라고 생각합니다 . 여러 댓글이는 것을 주장했다 패턴 이 아니라 안티 패턴 , 내가 동의하는 경향이있다.

또한 @JimmyJames의 답변과 동의합니다. 여기서 각 함수를 모든 입력을 명시 적 매개 변수 로 사용하는 블랙 박스로 취급하는 것이 좋은 프로그래밍 관행이라고 주장합니다 . 즉, 땅콩 버터와 젤리 샌드위치를 ​​만드는 기능을 작성하는 경우 다음과 같이 작성할 수 있습니다.

Sandwich make_sandwich() {
    PeanutButter pb = get_peanut_butter();
    Jelly j = get_jelly();
    return pb + j;
}
extern PhysicalRefrigerator g_refrigerator;
PeanutButter get_peanut_butter() {
    return g_refrigerator.get("peanut butter");
}
Jelly get_jelly() {
    return g_refrigerator.get("jelly");
}

하지만 것 보다 연습 의존성 주입을 적용하고 대신이처럼 쓸 수 :

Sandwich make_sandwich(Refrigerator& r) {
    PeanutButter pb = get_peanut_butter(r);
    Jelly j = get_jelly(r);
    return pb + j;
}
PeanutButter get_peanut_butter(Refrigerator& r) {
    return r.get("peanut butter");
}
Jelly get_jelly(Refrigerator& r) {
    return r.get("jelly");
}

이제 모든 의존성을 명확하게 함수 서명에 문서화하는 함수가 있으므로 가독성에 좋습니다. 결국,이다 진정한 순서에 있음을 make_sandwich당신은에 액세스 할 수 있어야합니다 Refrigerator; 따라서 이전 기능 서명은 냉장고를 입력의 일부로 사용하지 않음으로써 기본적으로 불분명했습니다.

보너스로 클래스 계층 구조를 올바르게 수행하고 슬라이싱을 피하는 등의 작업을 수행 make_sandwich하면 MockRefrigerator! (단위 테스트 환경에 액세스 할 수 없기 때문에이 방법으로 단위 테스트를 수행해야 할 수도 있습니다 PhysicalRefrigerator.)

모든 의존성 주입의 모든 사용이 비슷한 이름의 매개 변수를 호출 스택에서 여러 수준으로 배관 해야 한다는 것을 이해하지 못 하므로 요청한 질문에 정확하게 대답 하지는 않지만 ...이 주제에 대해 더 자세히 읽으려면 "종속성 주입"은 확실히 당신에게 적절한 키워드입니다.

이것은 커플 링에 대한 교과서 정의와 유사합니다 . 하나의 모듈은 다른 모듈에 크게 영향을 미치는 종속성이 있으며 변경 될 때 파급 효과를 만듭니다. 다른 의견과 답변은 이것이 전 세계에 비해 개선되었다는 것입니다. 이제 커플 링이 파괴적이기보다 더 명확하고 프로그래머가 쉽게 볼 수 있기 때문입니다. 그렇다고 수정해서는 안된다는 의미는 아닙니다. 커플 링을 제거하거나 줄이려면 리팩토링 할 수 있어야합니다.

이 답변이 귀하의 질문에 직접 대답하지는 않지만 개선 방법을 언급하지 않고 통과시키는 것을 거부합니다 (반 패턴으로 생각할 수 있으므로). 나는 당신과 다른 독자들이 "트램프 데이터"를 피하는 방법에 대한이 추가 논평으로부터 가치를 얻을 수 있기를 바랍니다 (Bob Dalgleish가 우리에게 도움이 되었기 때문에).

나는이 문제를 피하기 위해 더 많은 것을 할 것을 제안하는 답변에 동의합니다. 그러나 " 많은 인수를 전달하는 데 사용한 클래스를 전달하기 만하면 됩니다."로 넘어 가지 않고 이러한 인수 전달을 깊게 줄이는 또 다른 방법 은 프로세스의 일부 단계가 하위 레벨 대신 상위 레벨에서 발생하도록 리팩토링하는 것입니다. 하나. 예를 들어, 다음은 코드 이전 입니다.

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   FilterAndReportStuff(stuffs, desiredName);
}

public void FilterAndReportStuff(IEnumerable<Stuff> stuffs, string desiredName) {
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   ReportStuff(stuffs.Filter(filter));
}

public void ReportStuff(IEnumerable<Stuff> stuffs) {
   stuffs.Report();
}

에서해야 할 일이 많을수록이 상황은 더욱 악화됩니다 ReportStuff. 사용하려는 리포터 인스턴스를 전달해야 할 수도 있습니다. 그리고 전달해야 할 모든 종류의 의존성, 함수에 대한 중첩 함수.

내 제안은 모든 단계를 더 높은 수준으로 끌어 올리는 것입니다.이 단계에 대한 지식은 일련의 메소드 호출에 분산되는 대신 단일 메소드로 생활해야합니다. 물론 실제 코드에서는 더 복잡하지만 아이디어는 다음과 같습니다.

public void PerformReporting(StuffRepository repo, string desiredName) {
   var stuffs = repo.GetStuff(DateTime.Now());
   var filter = CreateStuffFilter(FilterTypes.Name, desiredName);
   var filteredStuffs = stuffs.Filter(filter)
   filteredStuffs.Report();
}

여기서 큰 차이점은 긴 체인을 통해 종속성을 전달할 필요가 없다는 것입니다. 한 수준이 아닌 몇 수준으로 평탄화하더라도 프로세스가 해당 수준에서 일련의 단계로 표시되도록 일부 "평 평화"를 달성하면 개선 된 것입니다.

이것은 여전히 ​​절차 적이며 아직 어떤 대상으로 바뀌지 않았지만, 무언가를 수업으로 바꾸어 달성 할 수있는 캡슐화 유형을 결정하는 좋은 단계입니다. 이전 시나리오 에서 깊게 연결된 메소드 호출 은 실제로 발생 하는 세부 사항을 숨기고 코드를 이해하기 어렵게 만들 수 있습니다. 이 작업을 과도하게 수행하여 고수준 코드를 사용하지 말아야 할 일을 알게하거나 너무 많은 일을 수행하여 단일 책임 원칙을 위반하는 방법을 만들 수 있지만 일반적으로 일을 평평하게하는 것이 약간 도움이된다는 것을 알았습니다 더 명확하게 코드를 개선하기 위해 점진적으로 변경합니다.

이 모든 작업을 수행하는 동안 테스트 가능성을 고려해야합니다. 체인 된 메서드 호출은 실제로 테스트 하려는 슬라이스에 대한 어셈블리에 진입 점과 출구 점이 없기 때문에 단위 테스트를 어렵게 만듭니다 . 이 평탄화를 사용하면 메소드가 더 이상 많은 종속성을 갖지 않으므로 테스트하기가 쉽고 모의자를 많이 요구하지 않습니다!

나는 최근에 17 개의 의존성 (모두 조롱해야 함)과 같은 클래스에 유닛 테스트를 추가하려고 시도했습니다. 나는 아직 모든 것을 얻지 못했지만 클래스를 세 가지 클래스로 나누었습니다. 각 클래스는 관련 된 명사 중 하나를 처리하고 최악의 경우 12 명, 약 8 명으로 종속성 목록을 얻었습니다. 최고.

테스트 가능성은 더 나은 코드를 작성 하도록 합니다. 단위 테스트를 작성해야 코드에 대해 다르게 생각할 수 있으며 단위 테스트를 작성하기 전에 버그가 몇 개인 지에 관계없이 시작부터 더 나은 코드를 작성할 수 있기 때문에 단위 테스트를 작성해야합니다.

문자 그대로 데메테르 법칙을 위반하지는 않지만 문제는 몇 가지면에서 비슷합니다. 질문의 요점은 리소스를 찾는 것이므로 Demeter of Law에 대해 읽고 그 조언 중 얼마나 많은 것이 귀하의 상황에 적용되는지 확인하십시오.

효율성, 유지 관리 성 및 구현 용이성 측면에서 항상 모든 것을 전달하는 오버 헤드 (지속적으로 15 가지 정도의 변수가 있음)가 아닌 오버 헤드가 아닌 특정 변수를 전역 변수로 사용하는 것이 가장 좋습니다. 따라서 (C ++의 개인 정적 변수로) 더 나은 범위 지정을 지원하는 프로그래밍 언어를 찾는 것이 네임 스페이스의 잠재적 혼란을 완화하고 변조 된 것을 찾는 것이 합리적입니다. 물론 이것은 단지 일반적인 지식입니다.

그러나 OP가 명시한 접근 방식은 함수형 프로그래밍을 수행하는 경우 매우 유용 합니다.

발신자는 아래의 모든 수준에 대해 알지 못하고 신경 쓰지 않기 때문에 반 패턴이 전혀 없습니다.

누군가 더 높은 수준 (매개 변수)을 호출하고 더 높은 수준이 작업을 수행 할 것으로 기대합니다. params와 함께 상위 레벨이하는 것은 발신자 비즈니스가 아닙니다. higherLevel은 params를 level1 (params)에 전달하여 최상의 방법으로 문제를 처리합니다. 절대적으로 괜찮습니다.

콜 체인이 표시되지만 콜 체인이 없습니다. 최상의 작업을 수행하는 기능이 맨 위에 있습니다. 그리고 다른 기능이 있습니다. 각 기능은 언제든지 교체 할 수 있습니다.