클래스 메소드의 수에는 제한이 있습니까?

내가 읽은 다른 디자인 책에서 때로는 클래스가 가지고 있어야하는 메소드의 수 (예 : Java 또는 C #과 같은 OO 언어를 고려)에 중점을 둡니다. 종종 그 책에 기록 된 예는 매우 깔끔하고 단순하지만 "심각한"복잡한 사례를 다루는 경우는 거의 없습니다.
그러나 범위는 5와 8 사이 인 것 같습니다.

프로젝트에서 속성, 속성, 속성, 설명, CreateDate 등의 속성으로 "Note"클래스를 개발했습니다.
그런 다음 getRelations (메모가 다른 문서에 할당 된 경우), getExpiryDate, ect와 같은 몇 가지 기본 방법입니다.

그러나 응용 프로그램 개발을 진행할 때는 더 많은 기능이 필요하므로 더 많은 방법이 필요했습니다.

클래스가 적은 메소드가 많을수록 더 느슨하게 결합된다는 것을 알고 있습니다. 이는 모듈 성과 재사용 성, 편집하기 쉬운면에서 좋은 이점입니다.
그런데 우리의 맥락에서 하위 클래스를 만들 필요가 없으며 심지어 필요한 모든 기능이 해당 클래스와 관련이 있다면 더 많은 메서드를 추가 할 수 있습니까?

15 가지 이상의 방법을 사용하는 경우 약간의 재 설계가 필요할 수 있음에 동의합니다.
그러나이 경우에도 일부 메소드 또는 상속을 삭제하는 것이 옵션이 아닌 경우 올바른 방법은 무엇입니까?

필요한만큼 많은 방법을 사용하십시오. 가능한 경우 공개 방법 수를 5-8 규칙으로 유지하려고합니다. 솔직히, 대부분의 사람들은 더 큰 문제를 해결해야하는 열렬한 슈퍼 메쏘드를 가지고있는 반대의 문제가 있습니다. 얼마나 많은 개인 도우미 메서드가 있는지는 중요하지 않습니다. 실제로 Java에서 8 개의 메소드 아래에 머물렀다면 생성자, toString 및 3 개의 속성에 대한 getter / setter 만있는 클래스로 한계에 도달 할 수 있습니다. 정확한 클래스는 아닙니다. 결론은 클래스가 얼마나 많은 메소드인지 걱정하지 마십시오. 수업이 관련없는 관심사를 취하지 않도록하고, 이해하기 쉬운 합리적인 공용 인터페이스가 있는지 걱정하십시오.

대답은 정말 간단합니다. 책임에 속하는 클래스에 모든 것을 넣지 만 책임을 지정할 때는주의하십시오.

때때로 큰 클래스는 다른 책임을 가진 작은 클래스의 복합입니다.

일반적으로 수업의 사용 또는 유지 관리가 어려워 질 때 책임을 더 작은 클래스로 나누려고합니다. 500 줄 이상의 수업은 거의 없습니다. 내 가장 큰 수업은 약 1.5k 정도입니다.

"클래스가 n과 m 사이의 메소드를 가져야합니다"와 같은 일반적인 규칙을 명시 할 수는 없습니다.

너무 많은 방법을 사용해야 할 이유가 없습니다 (OO 디자인). 메서드가 적은 클래스가 더 잘 분리되어있는 것도 사실이 아닙니다.

예를 들어 java.lang.String 클래스를보십시오. 문자열로 할 수있는 일이 너무 많기 때문에 많은 방법이 있습니다. 그럼에도 불구하고 강하게 결합되지 않았습니다.

왜 15와 같은 마법의 숫자가 좋은 디자인과 나쁜 디자인을 분리 할 수 ​​있는지 궁금합니다. 아니요, 쉽지 않습니다.

PMD에서 TooManyMethods 규칙 의 기본 동작은 10 개 이상의 메소드가있는 클래스를 식별하고 잠재적 오류로 플래그를 지정하는 것입니다. 그러나 이것은 임의의 숫자입니다. 구성에서 쉽게 변경됩니다. 이 숫자가 무엇이든 관계없이 개발자가 클래스를보고 문제가 있는지 확인하고 문제가 있는지 확인하는 플래그 일뿐입니다.

좀 더 구체적인 것은 7 +/- 2 규칙 일 수 있습니다 . 이것은 인간의 마음이 기억에서 5와 9 사이의 "객체"를 보유하고 이해할 수 있다는 것을 나타냅니다. 특정 클래스를 읽을 때 객체는 해당 클래스를 구성하는 메소드와 필드 일 가능성이 높습니다. 그러나 접근 자, 뮤 테이터 및 표준 작업 (예 toString(): hashCode(), 및 equals()Java)을 계산하지 않더라도 클래스에는 종종 9 개 이상의 필드와 메소드가 있습니다 .

가장 적절한 조치는 팬인 및 팬 아웃 과 커플 링 및 응집력에 대한 논의입니다 . 단일 책임 원칙 과 의 분리는 클래스가 할 또는 한 가지만으로도 한 가지를 표현한다 - 적용되어야한다. 이는 설계 또는 구현을 평가할 때 최대 / 최소 수의 메서드에 숫자를 할당하는 것보다 훨씬 낫습니다.