OOP : 언제 기본 클래스를 만들어야합니까?

Question

저는 많은 방법으로 많은 수업을 듣고 있습니다 (물론 25 가지가 서로 연관되어 있습니다). 나는 그것을 분리하고 파생 클래스와 기본 클래스를 생성해야하는지 잘 모르겠다. 미래에베이스에서 물려받은 또 다른 클래스에 대한 기회가 보이지 않습니다. 큰 클래스를 작은 부분으로 분해하기위한 추진 요인은 무엇입니까?

Answer 1

예, 20 가지가 넘는 방법을 사용하면 문제를 해결할 수 있습니다.

때때로 실험이 필요합니다.

또 다른 방법은 방법 수를 줄이는 방법을 살펴 보는 것입니다. 예를 들어 매개 변수의 다른 개수 및/또는 유형을 취하는 동일한 메소드 (이름으로)가 있습니까? 이 경우 해당 서명 간의 공통점을 볼 수 있습니다. 이것은 나를 또 다른 제안으로 이끈다.

4 개 이상의 매개 변수를 취하는 방법이있는 경우이를 살펴보면 어쩌면 그 자체로 클래스로 전환 할 수있는 옵션이있을 수 있습니다. 이로 인해 일부 기능이 새 클래스로 이동 될 수 있습니다.

클래스의 필드 수 (= 멤버 변수)를보십시오. 이러한 멤버 변수의 하위 집합에서 주로 작동하는 방식으로 메서드를 그룹화 할 수 있습니까? 어쩌면 당신은이 방법들과 그들이 작동하는 값들을 새로운 클래스로 바꿀 수 있습니다.

Answer 2

큰 클래스를 작은 부분으로 나누기위한 추진 요인은 무엇입니까?

별도의 개체로 논리적으로 이해해야 할 때해야합니다. 진정으로 정의한 모든 메소드가 단일 오브젝트에 대해 작동하고 논리적으로 다른 오브젝트에 관한 것으로 간주 될 수 없다면, 하나에 보관하십시오.

나는 내가 그것을 분할 및 파생 및 기본 클래스를 작성해야 확실하지 않다 대신

당신이 무슨 뜻인지 확실하지. 기본 클래스에서 일부 동작을 상속하지만 다른 클래스를 수정하거나 추가하는 객체가 필요할 때 기본 클래스에서 파생되지만 기본 클래스를 그대로 유지할 수 있습니다. 코드를 관리 가능한 덩어리로 분해하기 위해 상속받지 않습니다.

Answer 3

"대형 클래스"는 고전적인 "코드 냄새"입니다. 참조 : http://sourcemaking.com/refactoring/large-class

대형 클래스 인 경우 일 수도 있고 그렇지 않을 수도 있습니다.은 리팩토링에 적합한 후보를 의미합니다. 그것이 "코드 냄새"입니다 ... 코드가 좋을 수도 있지만, 좋은 모습 만 볼 수는 있습니다.

내가 링크 한 기사의 조언을 따르십시오. 그것이 PHP 용으로 작성된 것은 아니지만 개념과 전략은 여전히 ​​적용됩니다.