다른 것이 결코 바뀌지 않는다면 한 것이 다른 것과 얼마나 밀접하게 결합되어 있는지는 중요하지 않습니다. 나는 가능한 한 가장 느슨한 형태의 커플 링을 달성함으로써 변화하기 쉬운 이유를 찾는 것, 안정성을 추구하는 것보다 적은 이유를 찾는 것에 집중하는 것이 일반적으로 더 생산적이라는 것을 알았습니다.
디커플링 패키지를 분리하기 위해 때로는 겸손한 코드 복제를 선호하는 시점에서 매우 유용한 것으로 나타났습니다. 기본적인 예로, 수학 라이브러리를 사용하여 이미지 라이브러리를 구현할 수 있습니다. 나는 복사하기가 쉽지 않은 기본 수학 함수를 복제하지 않았습니다.
이제 내 이미지 라이브러리는 수학 라이브러리에 어떤 종류의 변경 사항이 있더라도 이미지 라이브러리에 영향을 미치지 않는 방식으로 수학 라이브러리와 완전히 독립적입니다. 안정성을 최우선으로 생각합니다. 이미지 라이브러리는 변경해야 할 다른 라이브러리와 분리되어 있기 때문에 변경해야 할 이유가 크게 줄어든만큼 안정적입니다. 보너스로 다른 라이브러리를 가져 와서 빌드하고 사용할 필요가없는 독립형 라이브러리 일 때 쉽게 배포 할 수 있습니다.
안정성은 저에게 매우 도움이됩니다. 나는 미래에 변화해야 할 이유가 점점 적은 잘 테스트 된 코드 모음을 만드는 것을 좋아합니다. 그것은 파이프 꿈이 아닙니다. 나는 80 년대 후반부터 그 이후로 전혀 바뀌지 않은 이후로 사용하고 다시 사용한 C 코드를 가지고 있습니다. 필자는 픽셀 지향 및 지오메트리 관련 코드와 같은 하위 수준의 항목이지만, 상위 수준의 항목은 많이 사용되지 않지만 여전히 많은 것을 유지하는 데 도움이되는 항목입니다. 그것은 거의 항상 외부가 없다면 더 적은 수의 것들에 의존하는 라이브러리를 의미합니다. 소프트웨어가 변화의 이유가 거의 없거나 전혀없는 안정적인 기반에 점점 더 의존 할 경우 안정성이 향상됩니다. 실제로 움직이는 부품의 수가 안정적인 부품보다 훨씬 많더라도 움직이는 부품 수가 적을수록 좋습니다.
느슨한 결합은 동일한 맥락에 있지만 느슨한 결합은 결합이없는 것보다 훨씬 덜 안정적이라는 것을 종종 발견합니다. 내가 생각했던 것보다 마음이 바뀌지 않는 훨씬 뛰어난 인터페이스 디자이너와 클라이언트가있는 팀에서 일하지 않는 한 순수한 인터페이스조차도 코드 전체에서 계단식 손상을 야기하는 방식으로 변경해야하는 이유를 종종 찾습니다. 인터페이스가 아닌 추상을 향해 의존성을 지향함으로써 안정성을 달성 할 수 있다는 아이디어는 인터페이스 디자인이 구현보다 처음부터 쉽게 이해되는 경우에만 유용합니다. 필자는 개발자가 충족해야한다고 생각한 설계 요구 사항을 감안하여 개발자가 매우 훌륭하지만 훌륭하지 않은 구현을 만들었을 때 종종 역전 된 것으로 나타났습니다.
따라서 안정성과 완벽한 디커플링을 선호하여 적어도 자신감있게 말할 수 있습니다. "수년 동안 사용되어 철저한 테스트를 통해 확보 된이 작은 격리 된 라이브러리는 혼란스러운 외부 세계에서 무슨 일이 있어도 변경이 필요하지 않습니다. " 외부에서 어떤 종류의 디자인 변경이 필요하든 상관없이 약간의 정신이 나옵니다.
커플 링 및 안정성, ECS 예
또한 엔터티 구성 요소 시스템을 좋아하고 시스템과 구성 요소 간의 종속성이 모든 원시 데이터에 직접 액세스하고 다음과 같이 조작하기 때문에 많은 밀접한 결합을 도입합니다.
구성 요소가 원시 데이터를 노출하기 때문에 여기의 모든 종속성은 매우 엄격합니다. 의존성은 추상화를 향하지 않고 원시 데이터 를 향하고 있습니다 . 즉, 각 시스템은 액세스를 요청하는 각 유형의 구성 요소에 대해 가능한 최대의 지식을 가지고 있습니다. 구성 요소는 모든 시스템이 원시 데이터에 액세스하고 조작하는 기능을 수행하지 않습니다. 그러나 매우 평평하기 때문에 이와 같은 시스템에 대해서는 추론하기가 매우 쉽습니다. 텍스처가 까다로워지면 렌더링 및 페인팅 시스템 만 텍스처 구성 요소에 액세스한다는 점을이 시스템에서 즉시 알 수 있으며, 텍스처에서 개념적으로 만 읽기 때문에 렌더링 시스템을 신속하게 배제 할 수 있습니다.
한편 느슨하게 연결된 대안은 다음과 같습니다.
... 데이터가 아닌 추상 기능에 대한 모든 종속성과 해당 다이어그램의 모든 단일 항목이 공용 인터페이스와 자체 기능을 노출합니다. 여기서 모든 종속성은 매우 느슨 할 수 있습니다. 객체는 서로 직접적으로 의존하지 않고 순수한 인터페이스를 통해 서로 상호 작용할 수도 있습니다. 여전히 복잡한 상호 작용을 고려할 때 특히 문제가 발생하면이 시스템에 대해 추론하기가 매우 어렵습니다. 또한 ECS보다 더 많은 상호 작용 (더 많은 커플 링, 더 느슨하지만)이있을 것입니다. 엔티티는 서로의 추상 공용 인터페이스에 대해서만 알고 있더라도 집계하는 구성 요소에 대해 알아야하기 때문입니다.
또한 디자인 변경 사항이 있으면 ECS보다 계단식 손상이 더 많으며, 모든 단일 항목이 멋진 객체 지향 인터페이스와 추상화를 제공하려고 시도하기 때문에 일반적으로 디자인 변경 이유와 유혹이 더 많습니다. 그것은 각각의 모든 작은 일이 디자인에 제약과 한계를 부과하려고 할 것이라는 생각과 함께 즉시 제공되며, 그러한 제약은 종종 디자인 변경을 보증하는 것입니다. 기능은 훨씬 더 제한적이며 원시 데이터보다 훨씬 더 많은 설계 가정을해야합니다.
실제로 위의 "플랫"ECS 시스템 유형은 복잡한 종속성의 복잡한 거미줄을 가진 가장 느슨하게 결합 된 시스템보다 훨씬 쉽게 추론하기가 훨씬 쉽다는 것을 알게되었습니다. ECS 버전은 시스템이 작동하는 데 필요한 적절한 데이터를 제공하는 것 외에는 책임이 없기 때문에 기존 구성 요소를 변경해야하는 경우가 있습니다. IMotion개인 데이터에 대한 불변량을 유지하면서 문제를 해결하고 관련이없는 원시 데이터 만 제공해야하는 모션 구성 요소와 복잡한 기능을 제공하는 인터페이스를 구현 하는 순수한 인터페이스 및 콘크리트 모션 오브젝트 설계의 어려움을 비교하십시오. 기능.
기능은 데이터보다 훨씬 더 어려워지기 때문에 종속성의 흐름을 데이터로 향하게하는 것이 종종 바람직하다고 생각합니다. 결국 몇 개의 벡터 / 행렬 라이브러리가 있습니까? 정확히 같은 데이터 표현을 사용하고 기능상 미묘하게 다른 몇 개가 있습니까? 기능적으로 미묘한 차이를 원하기 때문에 동일한 데이터 표현에도 불구하고 셀 수없이 많은 데이터를 보유하고 있습니다. 이미지 라이브러리는 몇 개입니까? 그중 몇 개가 다른 독특한 방식으로 픽셀을 나타 냅니까? 기능이 훨씬 더 불안정하고 많은 시나리오에서 데이터보다 설계 변경에 더 취약하다는 것을 거의 보여주지 않습니다. 물론 어느 시점에는 기능이 필요하지만 대부분의 종속성이 데이터를 향한 시스템을 설계 할 수 있습니다. 일반적으로 추상화 나 기능에 대한 것이 아닙니다. 이는 커플 링보다 안정성을 우선시합니다.
필자가 작성한 가장 안정적인 함수 (80 년대 후반부터 전혀 변경하지 않고 사용하고 재사용 한 종류)는 모두 배열을 받아 들인 지오메트리 함수와 같이 원시 데이터에 의존하는 함수였습니다. 복합체에 의존 수레와 정수가 아닌 그들 Mesh오브젝트 또는 IMesh인터페이스 또는 벡터 / 행렬 곱셈에 의존하는 단지 float[]또는 double[]에 의존하지 하나 FancyMatrixObjectWhichWillRequireDesignChangesNextYearAndDeprecateWhatWeUse.