답변:
인스턴스 변수가 너무 많으면 중복 코드와 직접 관련이 없으며 그 반대도 마찬가지입니다. 이 일반성에서이 진술은 허위입니다. 하나의 클래스에 중복 코드가없는 두 개의 개별 클래스를 던질 수 있습니다.이 클래스는 별도의 책임과 너무 많은 인스턴스 변수가 있지만 여전히 중복 코드가없는 새 클래스를 생성합니다.
그러나 실제 레거시 코드에서 책임이 너무 많은 클래스를 발견하면 코드를 작성한 프로그래머가 깨끗한 코드 또는 SOLID 원칙을 신경 쓰지 않았을 가능성이 높습니다 (최소한 코드 작성 시점은 아님). 다른 코드에서 중복 코드와 같은 냄새가 나지 않을 것입니다.
예를 들어, "복사-붙여 넣기 재사용"안티 패턴은 종종 적절한 리팩토링없이 오래된 방법을 복사하고 약간 수정하여 적용됩니다. 때로는이 작업을 수행하기 위해 멤버 변수를 복제하고 해당 변수도 약간 수정해야합니다. 이로 인해 인스턴스 변수가 너무 많은 클래스 가 생성 될 수 있습니다 (보다 정확하게는 너무 많은 유사한 인스턴스 변수가 보입니다). 이러한 상황에서 유사한 인스턴스 변수는 클래스의 다른 곳에서 반복되는 코드를 나타내는 지표 일 수 있습니다. 그러나 언급했듯이 이것은 인공적인 예이며 일반적인 규칙을 결론 지을 수는 없습니다.
인스턴스 변수가 너무 많으면 너무 많은 상태를 의미합니다. 상태가 너무 많으면 각 상태마다 약간 다른 중복 코드가 생성됩니다.
이것은 서브 클래스 또는 컴포지션이어야하는 너무 많은 일을하는 고전적인 단일 콘크리트 클래스입니다.
인스턴스 변수가 너무 많은 클래스를 찾으면 상태가 너무 많이 유지되고 각 경우에 약간 특화된 중복 된 코드 경로가 많지만 재사용이 가능한 메소드로 분리 될 수없는 복잡한 코드 경로가 있습니다. 이것은 가장 큰 소스 중 하나입니다 side effects.
이 범주에 속하지 않으며이를 해결하는 쉬운 방법은 이것에 대해 최소한 하나의 예외가 있습니다. Immutable개체는 고정 된 상태이기 때문에이 문제가 없습니다. 복잡한 상태 관리 또는 부작용이 발생할 가능성이 없습니다.
인용 한 내용은 특정 상황에서 볼 수 있습니다.
내 경험에 따르면, "일반적으로 많은 인스턴스 변수가 중복 된 코드를 나타냄"을 확인할 수 없습니다. 또한 이는 "코드 냄새"에 속하며 모순되는 냄새가 있습니다. 여기를보세요 :
http://c2.com/cgi/wiki?CodeSmell
흥미롭게도 "너무 많은 인스턴스 변수"는 "너무 적은 인스턴스 변수"만큼 좋은 코드 냄새입니다.
그러나 인스턴스 변수에는 너무 적거나 너무 많은 문제가 있습니다.
모든 인스턴스 변수는 객체의 일종의 상태를 의미 할 수 있습니다. 스타 티는 항상 신중한 치료가 필요합니다. 예기치 않은 동작을 피하려면 가능한 모든 stati 조합을 포함했는지 확인해야합니다. 당신은 항상 분명하게해야합니다 : 내 개체의 현재 상태는 무엇입니까? 이 각도에서, 많은 인스턴스 변수는 클래스가 유지 불가능 해졌음을 나타낼 수 있습니다. 또한 클래스가 너무 많아서 클래스가 너무 많은 작업을 수행함을 나타낼 수도 있습니다.
모든 인스턴스 변수는 감독을 유지해야하며, 어떤 방법으로 변수를 변경하는 방법이 있습니다. 따라서 갑자기 요리하는 모든 요리사를 더 이상 알지 못합니다. 늦은 밤에 피곤하게 프로그래밍 된 것 중 하나가 수프를 망칠 것입니다. 다시 말하지만, 그러한 변수가 너무 많으면 코드가 침투하기 어렵습니다.
반면 인스턴스 변수가 너무 적 으면 많은 메서드가 너무 많은 작업과 너무 많은 매개 변수로 정보를 처리해야 할 수 있습니다. 많은 메소드에 동일한 동등한 매개 변수를 제공하면 모든 메소드 가이 매개 변수와 매우 유사한 방식으로 수행됩니다. 이 경우 코드가 부풀어 오르기 시작합니다. 간단한 것들을 모으기 위해 많은 화면을 위아래로 스크롤하게됩니다. 여기에서 리팩토링이 도움이 될 수 있습니다. 하나의 인스턴스 변수와 하나의 명확한 입구를 도입하십시오. 그런 다음 모든 방법을 해제하십시오.
마지막으로 : 클래스의 많은 인스턴스 변수에 각각 setter와 getter가있는 경우 다른 클래스가이 첫 번째 클래스를 올바른 방식으로 사용하지 않음을 나타낼 수 있습니다. " 게터와 세터가 악한 이유 "에 대한 토론이 있습니다 . 간단히 말해, 클래스가 Rectangle일부 클래스를 제공 getX()하고 수십 개의 다른 클래스가 사용 rectangle.getX()하는 경우 "리플 효과"에 대해 강력하지 않은 코드를 작성하는 것입니다 (다른 코드에 영향을 미치는 코드 변경 정도). 유형을 int에서 double?로 변경하면 어떻게되는지 물어보십시오 . 이 논의에 따르면, 많은 rectangle.getX()통화는 실제로 더 나은 통화 여야합니다.rectanlge.calculateThisThingForMe(). 따라서 매우 간접적으로 복제 된 코드는 많은 인스턴스 변수에서 발생할 수 있습니다. 주변의 많은 클래스가 클래스 내에서 더 잘 이동 해야하는 매우 유사한 작업, 즉 복사 된 작업을 수행하는 많은 getter 및 setter를 사용하기 때문입니다.
인스턴스 변수가 많거나 적 으면 소프트웨어가 성장하는 동안 두 가지 방식을 모두 바꾸어 영구적 인 절충점을 유지합니다.
간단히 말해 : 코드 내에서 문제를 제대로 분리하지 않으면 모듈화되지 않은 코드가 생성되고 재사용이 저하되고 코드가 중복됩니다.
기능을 반복하지 않으면 코드가 중복되지 않으며 많은 인스턴스 변수가 문제가되지 않습니다.
기능을 반복하려고하면 모듈식이 아닌 모 놀리 식 코드를 재사용 할 수 없습니다. 너무 많은 일을하고 할 수있는 일만 할 수 있습니다. 유사하지만 동일하지 않은 작업을 수행하려면 모 놀리 식 코드를 깨뜨리는 것보다 잘라내어 붙여 넣는 것이 더 쉬워집니다. 경험 많은 프로그래머들은 중복 된 코드가 지옥으로가는 길이라는 것을 알고 있습니다.
따라서 많은 인스턴스 변수 자체가 문제의 근본 원인은 아니지만 문제가 다가오는 것은 강력한 "냄새"입니다.
"뒤에있을 수 없다"라는 언어는 "반드시 따라야한다"라는 말보다 약하기 때문에 저자는 반드시 발생해야한다고 주장하지는 않지만 결국 일어날 것이라고 주장하고있다. 기능을 재사용해야하지만 코드가 모듈식이 아니기 때문에 사용할 수없는 경우
n부울 변수는 내부 상태 공간을 만듭니다2^n. 객체에 관측 가능한 상태 가 많지 않은 경우가 많지만 그 상태를 모두 단일 객체로 만들었으므로 내부적으로 여전히 모든 것을 처리해야합니다.