DRY 및 OOD에 의한 코드 커플 링 소개

DRY와 코드 커플 링에 대한 지침을 찾고 있습니다. 코드를 복제하는 것을 좋아하지 않으며 관련없는 모듈 간의 코드 커플 링도 좋아하지 않습니다. 따라서 복제가 도입 된 후 1 년 동안 동일한 중복 코드를 찾으면 중복 코드를 리팩터링합니다. 그러나 실제 환경이 훨씬 더 예측하기 어려운 상황이 점점 더 많이 발생하고 있으며 코드를 리팩터링 한 후 코드를 다시 계산해야하는 상황이 발생합니다.

예를 들어, 휘발유 자동차, 휘발유 SUV, 전기 자동차 및 전기 SUV를 처리하는 코드가있는 경우 중복 된 코드를 "가솔린"계층 구조와 "전기"계층 구조로 다시 리팩토링했다고 가정합니다. 여태까지는 그런대로 잘됐다. 그런 다음 회사에서 하이브리드 자동차와 하이브리드 세미를 소개합니다. 원래 세미 계층 자체의 핵심 변경이 필요합니다. 아마도 휘발유와 전기 계층 구조 사이에 "구성"이 필요할 수 있습니다.

분명히 코드 복제는 위의 모든 제품에 공통적 인 변경을 구현하는 데 시간이 걸리기 때문에 나쁘다. 그러나 공통 코드를 리팩토링하면 제품 별 변형을 도입하기가 어려워지고 버그를 수정하기 위해 코드 줄을 찾아야 할 때 많은 "클래스 점핑"이 발생합니다. 상위 상위 클래스에서 한 번만 변경하면 모든 하위 항목에서 트리거 회귀 버그를 트리거합니다.

DRY와 원치 않는 코드 커플 링간에 최적의 균형을 유지하는 방법은 무엇입니까?

중복 코드를 "가솔린"계층 구조와 "전기"계층 구조로 리팩토링했다고 가정 해 보겠습니다. 여태까지는 그런대로 잘됐다.

그런 다음 회사에서 하이브리드 자동차와 하이브리드 세미를 소개합니다. 원래 세미 계층 자체의 핵심 변경이 필요합니다. 휘발유와 전기 계층 구조 사이에 "구성"이 필요할 수 있습니다.

이것이 사람들이 상속에 대한 구성으로 나아가는 주된 이유 중 하나라고 생각합니다.

상속은 당신이 묘사 한 것과 같은 개념적 변화가있을 때 큰 구조 조정을 강요합니다.

구조 조정이 '너무 크거나 어렵다'면 사람들은이를 피하기 위해 중복 코드를 작성합니다.

코드를 상속 체인 위로 이동하여 복제본을 원격 처리하지 않고 도우미 클래스 또는 서비스로 코드를 옮긴 다음 필요한 경우 컴포지션의 일부로 해당 클래스를 주입 할 수 있습니다.

결과 디자인이 OOP인지 여부는 논쟁의 여지가있다

DRY 원칙에 따라 올 바르면 관련이없는 모듈 간의 커플 링을 증가시킬 수 있습니다. 특히 큰 소프트웨어 시스템에서는 DRY를 따르지 않는 것이 더 나은 대안이 될 수 있습니다.

불행하게도, 당신의 예를 잘 이것을 입증하기 위해 적합하지 않습니다 - 문제가이 고전 오류로 인해 발생 설명 잘못된 상속의 최적 사용. 그러나 위에서 작성한 내용에 대해 공통 코드를 공통 기본 클래스 또는 도우미 클래스 (조성)로 리팩토링하는 것은 중요하지 않습니다. 두 경우 모두 공통 코드를 라이브러리 L에 넣고 이전에 관련되지 않은 두 개의 프로그램 A 및 B에서 해당 라이브러리를 참조해야 할 수 있습니다.

이전에 A와 B가 완전히 관련이 없다고 가정하고 독립적으로 버전을 지정하고 릴리스하고 배포 할 수 있습니다. 그러나 공통 코드를 공유 라이브러리 L에 넣으면 A에 대한 새로운 요구 사항으로 인해 L이 변경되어 B가 변경 될 수 있습니다. 따라서 추가 테스트가 필요하고 B에 대한 새로운 릴리스 및 배포주기가 필요할 수 있습니다.

DRY 원칙을 기꺼이 포기하지 않으려면 어떻게이 상황을 처리 할 수 ​​있습니까? 글쎄, 이것에 접근하는 잘 알려진 전술이 있습니다.

1. 하나의 공통 버전 번호, 공통 빌드, 릴리스 및 배치 프로세스 및 고도의 자동화로 A, B 및 L을 동일한 제품의 일부로 유지하십시오.

2. 또는 부 버전 번호 (호환되지 않는 변경 사항 없음)와 메이저 버전 번호 (중단 변경 사항이있을 수 있음)를 사용하여 L을 자체 제품으로 만들거나 A와 B가 각각 다른 버전의 L 버전을 참조하도록합니다.

3. L을 가능한 한 SOLID로 만들고 이전 버전과의 호환성을 관리하십시오. L에서 더 많은 모듈을 수정하지 않고 재사용 할 수 있으면 (OCP), 변경이 발생할 가능성이 줄어 듭니다. "SOLID"의 다른 원칙은 이러한 목표를 지원하는 데 도움이됩니다.

4. L뿐 아니라 A와 B에도 자동 테스트를 사용하십시오.

5. 시스템에 한 곳에만 존재해야하는 비즈니스 로직은 좋은 후보입니다. "유사하게 보인다"고 미래에 다르게 다를 수있는 것은 나쁜 후보입니다.

서로 관련이없는 서로 다른 팀이 A와 B를 개발, 유지 관리 및 발전시킬 때 DRY 원칙은 그다지 중요하지 않습니다. DRY는 유지 관리 성과 진화성에 관한 것이지만 두 팀이 개별 유지 관리 노력을 제공하는 것이 때로는 제품을 묶는 것보다 더 효과적 일 수 있습니다 약간의 재사용으로 인해 함께.

결국, 그것은 절충입니다. 더 큰 시스템에서 DRY 원칙을 따르려면 강력하고 재사용 가능한 구성 요소를 만드는 데 훨씬 더 많은 노력을 기울여야합니다 (일반적으로 예상보다 많은 양). 가치가있을 때와 그렇지 않을 때 판단을 신뢰해야합니다.

DRY는 또 다른 구조적 규칙입니다. 그것은 당신이 그것을 극단적으로 가져 가면 그것을 무시하는 것처럼 나쁘다는 것을 의미합니다. 다음은 구조적 사고 방식에서 벗어날 수있는 비유입니다.

당신의 쌍둥이를 사랑하십시오. 클론을 죽여라.

키보드 입력을 피하기 위해 맹목적으로 복사 및 붙여 넣기를하면 무의식적으로 클론이 생성됩니다. 물론 그들은 당신이 원하는 것을하지만, 이제 그 행동을 바꾸는 것이 너무 비싸기 때문에 무게가 가중됩니다.

다른 책임으로 인해 동일한 코드로 동일한 행동을 재현 할 때 현재 동일한 요구가 발생하지만 다른 변경이 발생할 수 있으므로 시간이 지남에 따라 개인으로 자유롭게 변경하고 성장 해야하는 쌍둥이가 있습니다.

DNA (코드)를 원하는대로 스캔 할 수 있습니다. 클론과 쌍둥이는 당신이하는 모든 것이 그들을 보는 것이라면 구별하기 어렵습니다. 당신이 필요로하는 것은 그들이 살고있는 맥락을 이해하는 것입니다. 왜 그들이 태어났는가. 그들의 궁극적 인 운명이 무엇인지.

ABC 회사에서 근무한다고 가정 해 보겠습니다. A, B 및 C의 세 회사 임원이 운영합니다. 모두 소프트웨어 제품을 만들고 싶어하지만 각 부서마다 부서가 있습니다. 그들은 모두 당신이 작게 시작하기를 원합니다. 지금은 간단한 메시지를 출력하십시오. "Hello World"라고 씁니다.

싫어, 회사 이름을 거기에 넣기를 원합니다.

B는 그것을 좋아하고, 혼자두고 회사 이름을 스플래시 화면에 추가하기를 원합니다.

C는 계산기를 원하고 메시지가 시작하는 방법이라고 생각했습니다.

당신이 확신하는 한 가지,이 사람들은이 프로젝트의 내용에 대해 매우 다른 생각을 가지고 있습니다. 때때로 그들은 동의 할 것입니다. 때때로 그들은 다른 방향으로 당신을 끌 것입니다.

코드가 독립적으로 변하는 기능을 생성하기 때문에 코드를 복제하면 트윈을 생성하게됩니다. 타이핑이 번거롭고 복사하여 붙여 넣기가 쉬워 코드를 복제하면 사악한 클론이 만들어집니다.

A, B 및 C는 코드가 제공해야하는 다른 마스터입니다. 한 줄의 코드만으로는 둘 이상의 마스터를 제공 할 수 없습니다.