속보 공공 멤버 함수

Question

나는 나 자신이 여러 개인 멤버 함수로 그것을 분할 찾아 그 함수에서 같은 여러 가지 작업을 수행하는 클래스의 공용 멤버 함수 ..

void Level::RunLogic(...); 

를 쓸 때 . public 멤버 함수를 여러 함수로 나눌 필요가 없습니다. 왜냐하면 여러분은 다른 함수없이 하나의 일을하지 않을 것이고, 사용자가 어떤 순서로 무엇을해야할지 걱정하지 않기를 원할 것입니다. RunLogic() 함수는 다음과 같은 모양이됩니다 ...

void Level::RunLogic(...) { 
DoFirstThing(); 
DoSecondThing(); 
DoThirdThing(); 
} 

DoThing 기능은 개인 멤버 함수입니다. Code Complete에서 Steve McConnel은 클래스에 포함 된 함수의 수를 줄이는 것을 권장하지만 모든 코드를 하나의 함수에 넣는 것이 아닙니다. 그의 진정한 의미에 대한 나의 가정은 클래스가 너무 많은 기능을 가져서는 안된다는 것입니다. 그러나 나는 다른 프로그래머가 이것에 관해 어떻게 생각하는지 궁금합니다.

또한 공용 멤버 함수에서 구현 세부 사항이 점점 더 적어지고 대부분의 작업은 작은 개인 멤버 함수로 옮겨 가고 있습니다. 분명히 이것은 더 많은 함수를 생성하지만 ... 그게 질문이있는 곳입니다.

Answer 1

내가 사용하는 하나의 규칙은 3 가지 규칙입니다. 다른 곳에서 똑같은 일을 3 번하고 있다면 공유 된 동작을 캡슐화하는 별도의 (개인적 일 수도있는) 멤버 함수가 필요할 것입니다.

이 상황에서 일반적으로 사용하는 유일한 규칙은 읽기 쉽습니다. IDE에서 전체 화면을 채우는 멤버 함수를 살펴보면 모든 코드 경로와 가능한 잘못된 순서를 추적하는 것이 어렵다는 것을 알게되었습니다. 이 경우 하나의 모 놀리 식 멤버 함수를 두 개 이상의 개인 도우미 함수로 나눌 수 있습니다.

클래스에 대한 함수의 수에 대한 완전한 설명은 함수의 수와 관련된 가장 큰 위험이 주로 외부에서 사용 가능한 인터페이스의 복잡성과 관련되어 있음을 기억하십시오. 다른 사람이 작업 할 수 있도록 제공하는 진입 점이 많을수록 (예 : 공개 멤버 중 하나의 버그, 잘못된 입력 등으로 인해) 문제가 발생할 가능성이 커집니다. private 멤버 함수를 추가해도 public API의 복잡성은 증가하지 않습니다.

Answer 2

각 메소드가 하나의 작은 태스크를 처리하고 각각의 개인 메소드를 설명하는 개별 메소드로 분리하는 것이 좋습니다. 메소드와 메소드 이름을 깨면 로직 코드가 더 읽기 쉽습니다! 비교 :

double average(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) { 
    sum += n; 
    } 
    return sum/numbers.length; 
} 

에 :

double sum(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) sum += n; 
    return sum; 
} 

double average(double[] numbers) { 
    return sum(numbers)/numbers.length; 
} 

코드 전체 주소 각 클래스가 노출하는 인터페이스가 아닌 구현입니다.

작은 메소드를 패키지로 보호하는 것이 더 합리적 일 수 있으므로 복잡한 RunLogic 만 테스트 할 수 있으므로 쉽게 테스트 할 수 있습니다.

Answer 3

당신은 실수로 FF로 규칙을 따르고 있습니다 : 좋은 일이

A class should have only one reason to change/Single responsibility principle 

합니다. 책임을 적절히 분리하여 앱이 쉽게 깨지지 않도록해야합니다. change

Answer 4

공개 방법을 간단하게 유지하고 기능을 여러 개인 방법으로 나누고 싶을 수도 있습니다.

McConnell은 수업에 보관하는 방법의 수를 줄여야한다고 생각합니다.

두 가지 목표는 실제로 이상하지 않습니다. McConnell이 당신의 기능을 오랫동안 줄여서 그들의 수를 줄이기를 주창 할 것이라고 나는 생각하지 않습니다. 오히려 이러한 개인 메서드 중 일부를 공용 클래스에서 사용할 수있는 하나 이상의 유틸리티 클래스로 푸시하는 것을 고려해야합니다.

이 작업을 수행하는 가장 좋은 방법은 물론 코드의 세부 사항에 달려 있습니다.

Answer 5

기능 분할에 동의합니다.

필자는 항상 배워 왔고 하나의 캡슐화 된 작업을 수행하기 위해 함수가 정의되었다는 지식에 매달 렸습니다. 여러 가지 일을하는 것처럼 보이면 다시 고려해야합니다. 그리고 유사하거나 관련된 함수를 함께 캡슐화하는 클래스.

내 의견으로는 이러한 작업을 분할하여 하나의 공용 멤버를 사용하여 클래스가 의도 한대로 중요한 작업을 수행 할 수있게하면서 유지 관리를 용이하게합니다. 또한 동일한 복합 메소드에 여러 유사한 섹션 코드가 있으며 매개 변수가있는 단일 일반 함수로 다시 고려 될 수 있다는 것을 종종 발견합니다. 가독성과 유지 보수성이 모두 향상됩니다. 심지어는 코드의 양도 줄일 수 있습니다.

Answer 6

public 멤버 함수를 최대한 작게 유지하는 이점은 보이지 않습니다 (코드 줄로 측정). 일반적으로 긴 함수는 읽기 쉽지 않은 경향이 있으므로 대부분의 경우 큰 함수의 구현을 전파하면 클래스의 일부인지 여부에 관계없이 가독성이 향상됩니다.

클래스를 가능한 한 작게 유지하는 것은 인터페이스의 공개 부분과 캡슐화 된 데이터의 양에 특히 중요합니다. 그 이유는 많은 데이터 멤버와 공용 함수를 가진 클래스가 데이터 캡슐화의 이점을 취소하기 때문입니다.

Answer 7

내가 사용하는 '경험 법칙'은 한 번에 하나 이상의 화면을 풀 공간 이상 사용하지 않는다는 것입니다. 오히려 단순하지만, 한 번에 한 화면 씩 '모든 것을'사용할 수있을 때 도움이됩니다. 또한 정의에 따라 한 가지 방법의 복잡성을 제한합니다. 추가 유지 관리, 업그레이드 및 버그 수정 (!)을 위해 동료에게 작업을 넘겨 줄 것으로 예상되면 간단하게 유지하십시오. 이를 염두에두고, 공용 메서드를 단순하게 유지하는 것이 거의 항상 올바른 선택이라는 데 동의합니다.