단일 참조를 가진 개인 메소드는 나쁜 스타일입니까?

일반적으로 개인 메서드를 사용하여 클래스의 여러 곳에서 재사용되는 기능을 캡슐화합니다. 그러나 때로는 큰 공개 방법을 사용하여 각기 개인 방법으로 작은 단계로 나눌 수 있습니다. 이렇게하면 공용 메서드가 더 짧아 지지만 메서드를 읽는 사람이 다른 개인용 메서드로 이동하면 가독성이 손상 될 것으로 걱정됩니다.

이것에 대한 합의가 있습니까? 긴 공용 메소드를 사용하거나 각 조각을 재사용 할 수없는 경우에도 더 작은 조각으로 나누는 것이 더 낫습니까?

아니요, 이것은 나쁜 스타일이 아닙니다. 사실 그것은 아주 좋은 스타일입니다.

개인 기능은 단순히 재사용 성으로 인해 존재할 필요는 없습니다. 그것이 그것들을 만들어야 할 좋은 이유 중 하나이지만, 또 다른 이유는 분해입니다.

너무 많은 기능을 고려하십시오. 길이는 100 줄이며 추론하기가 불가능합니다.

이 기능을 더 작은 조각으로 나누면 여전히 이전과 같이 많은 작업을 "하지만"더 작은 조각으로 수행합니다. 설명이 필요한 다른 함수를 호출합니다. 주요 함수는 거의 책처럼 읽습니다 : A, B, C 등. 특정 기능은 반드시 다른 기능에서 샌드 박스 처리됩니다. 범위가 다릅니다.

큰 문제를 작은 문제로 분해 할 때 작은 문제 (기능)가 한 번만 사용 / 해결 된 경우에도 몇 가지 이점이 있습니다.

• 가독성. 아무도 모 놀리 식 함수를 읽고 그 기능을 완전히 이해할 수 없습니다. 계속 자기 자신에게 거짓말을하거나 이해하기 쉬운 한 입 크기의 덩어리로 나눌 수 있습니다.

• 참조의 지역. 이제 변수를 선언하고 사용하는 것이 불가능 해졌으며, 계속 사용하고 100 줄 후에 다시 사용했습니다. 이러한 기능은 범위가 다릅니다.

• 테스트. 클래스 의 공개 멤버 를 단위 테스트하는 것만 필요하지만 특정 개인 멤버도 테스트하는 것이 바람직 할 수 있습니다. 테스트에서 이점을 얻을 수있는 긴 함수의 중요한 섹션이 있으면 별도의 함수로 추출하지 않고 독립적으로 테스트 할 수 없습니다.

• 모듈성. 개인 함수가 있으므로 여기에서만 사용하거나 재사용 가능한지 여부에 관계없이 별도의 클래스로 추출 할 수있는 하나 이상의 함수를 찾을 수 있습니다. 이전에는이 ​​별도의 클래스는 공용 인터페이스가 필요하기 때문에 테스트하기가 더 쉬울 것입니다.

큰 코드를 이해하기 쉽고 테스트하기 쉬운 작은 조각으로 나누는 아이디어는 밥 삼촌의 책 Clean Code의 핵심 입니다. 이 답변을 쓸 당시이 책은 9 살이되었지만 그 당시와 마찬가지로 오늘날에도 관련이 있습니다.

아마 좋은 생각입니다!

긴 선형 동작 시퀀스를 별도의 함수로 분리하여 코드베이스의 평균 함수 길이를 줄이는 데 문제가 있습니다 .

function step1(){
  // ...
  step2(zarb, foo, biz);
}

function step2(zarb, foo, biz){
  // ...
  step3(zarb, foo, biz, gleep);
}

function step3(zarb, foo, biz, gleep){
  // ...
}

이제 실제로 소스 라인을 추가 하고 전체 가독성을 크게 줄였습니다 . 특히 상태를 추적하기 위해 각 함수 사이에 많은 매개 변수를 전달하는 경우. 이케!

그러나 하나 이상의 명확한 목적을 제공하는 순수한 함수로 하나 이상의 행을 추출한 경우 ( 한 번만 호출하더라도 ) 가독성이 향상되었습니다.

function foo(){
  f = getFrambulation();
  g = deglorbFramb(f);
  r = reglorbulate(g);
}

실제 상황에서는 쉽지 않을 수 있지만, 충분히 오래 생각하면 순수한 기능을 사용하는 경우가 종종 있습니다.

동사 이름이 좋은 함수가 있고 부모 함수가 함수를 호출하면 실제로 산문의 단락처럼 읽습니다.

그런 다음 몇 주 후에 더 많은 기능을 추가하고 실제로 그 기능 중 하나를 재사용 할 수 있다는 사실을 알게 된다면 아, 기쁜 기쁨입니다! 놀라운 기쁨!

정답은 상황에 따라 크게 다릅니다. @Snowman은 대규모 공공 기능을 파괴 할 때의 긍정적 인 점을 다루고 있지만, 우려하는 바에 따라 부정적인 영향을 미칠 수도 있다는 점을 기억해야합니다.

• 부작용이있는 많은 개인 함수는 코드를 읽기 어렵고 깨지기 쉽습니다. 이러한 개인 기능이 서로의 부작용에 의존 할 때 특히 그렇습니다. 단단히 결합 된 기능을 피하십시오.

• 추상화가 새고 있습니다. 작업 수행 방법 또는 데이터 저장 방법을 가장 잘 설명하는 것은 중요하지 않지만 실제로 수행되는 경우가 있으므로이를 식별하는 것이 중요합니다.

• 의미론과 맥락 문제. 함수가 이름에서하는 일을 명확하게 포착하지 못하면 가독성을 줄이고 공용 함수의 취약성을 다시 증가시킬 수 있습니다. 많은 수의 입력 및 출력 매개 변수로 개인용 함수 작성을 시작할 때 특히 그렇습니다. 그리고 공용 함수에서 호출하는 개인 함수를, 개인 함수에서 호출하는 공용 함수를 볼 수 없습니다. 이로 인해 개인 기능에서 "버그 수정"이 발생하여 공용 기능이 중단 될 수 있습니다.

• 심하게 분해 된 코드는 다른 사람보다 항상 저자에게 더 명확합니다. 그렇다고해서 여전히 다른 사람들에게 명확하지 않다는 것을 의미하는 것은 아니지만 글을 쓰는 시점 bar()이전 foo()에 호출해야한다고 완벽하게 이해하는 것은 쉬운 일입니다.

• 위험한 재사용. 귀하의 공공 기능은 각 개인 기능에 대해 가능한 입력을 제한했을 것입니다. 이러한 입력 가정이 제대로 포착되지 않으면 (모든 가정을 문서화하기 어렵다) 누군가가 개인 함수 중 하나를 부적절하게 재사용하여 코드베이스에 버그를 도입 할 수 있습니다.

절대 길이가 아니라 내부 응집력과 커플 링을 기준으로 함수를 분해합니다.

복잡성을 해소하기위한 수단으로 코드 블록을 뽑아내는 가치 인 IMHO는 종종 다음과 같은 복잡성의 차이와 관련이 있습니다.

1. 코드는 무엇의 완전하고 정확한 인간의 언어로 설명 이 코너 케이스를 처리하는 방법을 포함 하고,

2. 코드 자체

코드가 설명보다 훨씬 복잡한 경우 인라인 코드를 함수 호출로 바꾸면 주변 코드를 더 쉽게 이해할 수 있습니다. 반면에 일부 개념은 인간 언어보다 컴퓨터 언어로 더 읽기 쉽게 표현 될 수 있습니다. w=x+y+z;예를 들어보다 읽기 쉬운 것으로 간주 w=addThreeNumbersAssumingSumOfFirstTwoDoesntOverflow(x,y,z);합니다.

큰 기능이 분리됨에 따라 하위 기능의 복잡성과 설명에 대한 차이가 점점 줄어들고 추가 세분화의 이점이 줄어 듭니다. 설명이 코드보다 복잡 할 정도로 분할 된 경우, 추가 분할은 코드를 악화시킵니다.

균형 잡힌 도전입니다.

미세할수록 좋습니다

private 메소드 는 포함 된 코드 의 이름 과 때로는 의미있는 서명을 효과적으로 제공합니다 (매개 변수의 절반이 명확하지 않은 문서화되지 않은 상호 의존성이있는 임시 임시 데이터 가 아닌 경우 ).

이름 이 호출자 에게 의미있는 계약 을 제안 하고 개인 메소드의 계약이 이름이 제안하는 것과 정확하게 일치하는 한 , 코드 구조에 이름을 부여하는 것이 일반적으로 좋습니다 .

코드의 작은 부분에 대한 의미있는 계약을 스스로 생각하게함으로써 초기 개발자는 일부 테스트를 수행하기 전에도 몇 가지 버그를 발견 하고이를 피할 수 있습니다. 이것은 개발자가 간결한 이름 지정을 위해 노력하고 있고 (간단한 소리지만 정확함) 간결한 이름 지정이 가능하도록 개인 방법의 경계를 기꺼이 조정하려는 경우에만 작동합니다.

추가적인 이름 지정은 코드 자체 문서 작성에 도움이되므로 후속 유지 보수에도 도움이됩니다 .

• 작은 코드 조각을 통한 계약
• 상위 레벨의 메소드는 때때로 짧은 호출 순서로 바뀌며, 각 호출은 일반적이고 가장 바깥 쪽 오류 처리의 얇은 계층과 함께 중요하고 뚜렷한 이름의 무언가를 수행합니다. 이러한 방법은 모듈의 전체 구조에 대해 빠르게 전문가가되어야하는 사람에게는 소중한 교육 리소스가 될 수 있습니다.

너무 좋아질 때까지

작은 코드 덩어리에 이름을 부여하고 너무 많은 너무 작은 개인 메소드로 끝날 수 있습니까? 확실한. 다음 증상 중 하나 이상이 방법이 너무 작아서 유용하지 않음을 나타냅니다.

• 동일한 필수 논리에 대한 대체 서명을 나타내지 않고 단일 고정 호출 스택을 나타내는 과부하가 너무 많습니다.
• 동일한 개념을 반복적으로 참조하기 위해 사용되는 동의어 ( "이름 지정")
• XxxInternal또는 과 같은 많은 기능성 명명 장식 DoXxx, 특히 그것들을 도입하는 데 통일 된 계획이없는 경우.
• 서투른 이름은 구현 자체보다 거의 길다. LogDiskSpaceConsumptionUnlessNoUpdateNeeded

다른 사람들이 말한 것과는 달리, 긴 공개 방법은 개인 방법으로 분해되어 수정 되지 않는 디자인 냄새라고 주장합니다 .

그러나 때로는 작은 단계로 나눌 수있는 큰 공개 방법이 있습니다.

이 경우 각 단계는 각자 책임이있는 일류 시민이어야한다고 주장합니다. 객체 지향 패러다임에서는 각 단계마다 쉽게 식별 할 수있는 단일 책임을 가지며 책임이 분명한 방식으로 이름을 지정할 수 있도록 인터페이스와 구현을 만드는 것이 좋습니다. 이를 통해 (이전의) 대규모 공용 방법과 각 개별 단계를 서로 독립적으로 단위 테스트 할 수 있습니다. 그것들도 모두 문서화되어야합니다.

왜 개인 메소드로 분해되지 않습니까? 몇 가지 이유는 다음과 같습니다.

• 긴밀한 결합 및 테스트 가능성. 공용 메소드의 크기를 줄이면 가독성이 향상되었지만 모든 코드는 여전히 밀접하게 결합됩니다. 테스트 프레임 워크의 고급 기능을 사용하여 개별 개인용 메소드를 개별적으로 테스트 할 수 있지만 개인용 메소드와 독립적으로 공용 메소드를 쉽게 테스트 할 수는 없습니다. 이것은 단위 테스트의 원칙에 위배됩니다.
• 수업 규모와 복잡성. 메서드의 복잡성을 줄 였지만 클래스의 복잡성을 높였습니다. public 메소드는 읽기가 쉽지만 클래스의 동작을 정의하는 함수가 많기 때문에 클래스를 읽기가 더 어렵습니다. 제가 선호하는 것은 작은 단일 책임 클래스에 대한 것이므로 긴 방법은 클래스가 너무 많은 일을하고 있다는 신호입니다.
• 쉽게 재사용 할 수 없습니다. 코드 본문이 성숙할수록 재사용 성이 유용한 경우가 종종 있습니다. 단계가 개인용 메소드 인 경우 먼저 추출하지 않고 다른 곳에서는 재사용 할 수 없습니다. 또한 다른 단계가 필요한 경우 복사 붙여 넣기를 권장 할 수 있습니다.
• 이러한 방식으로 분할하는 것은 임의적 일 수 있습니다. 긴 공개 방법을 분할하는 것이 책임을 클래스로 나누는 것처럼 많은 생각이나 디자인 고려 사항을 취하지 않는다고 주장합니다. 각 클래스는 적절한 이름, 문서 및 테스트로 정당화되어야하지만 개인 메서드는 그다지 고려되지 않습니다.
• 문제를 숨 깁니다. 그래서 당신은 공개 방법을 작은 개인 방법으로 나누기로 결정했습니다. 이제 아무런 문제가 없습니다! 점점 더 많은 전용 메소드를 추가하여 더 많은 단계를 계속 추가 할 수 있습니다! 반대로, 나는 이것이 중요한 문제라고 생각합니다. 후속 버그 수정 및 기능 구현이 뒤따를 클래스에 복잡성을 추가하기위한 패턴을 설정합니다. 머지 않아 당신의 개인적인 방법이 커져서 나누어 져야 할 것입니다.

하지만 방법을 읽는 사람이 다른 개인 방법으로 이동하면 가독성이 손상 될까 걱정됩니다.

이것은 최근 동료 중 한 사람과 함께 한 논쟁입니다. 그는 동일한 파일 / 방법으로 모듈의 전체 동작을 수행하면 가독성이 향상된다고 주장합니다. 모든 코드를 함께 사용 하면 코드를 따라 가기 가 더 쉽지만 , 복잡성이 커짐에 따라 코드를 추론 하기가 쉽지 않습니다 . 시스템이 성장함에 따라 전체 모듈을 전체적으로 추론하기가 어렵습니다. 복잡한 논리를 단일 책임을 갖는 여러 클래스로 각각 분해하면 각 파트에 대해 추론하기가 훨씬 쉬워집니다.