OOP에 대한 중요한 도전자

Question

내가 이해한 바로는 OOP는 대규모 프로젝트에 가장 일반적으로 사용되는 패러다임입니다.또한 대규모 시스템의 일부 소규모 하위 집합이 다른 패러다임을 사용한다는 것도 알고 있습니다(예:선언적 SQL) 그리고 낮은 수준의 컴퓨팅 OOP에서는 실제로 실현 가능하지 않다는 것도 깨달았습니다.그러나 일반적으로 더 높은 수준의 솔루션 조각은 거의 항상 OOP 방식으로 결합되는 것 같습니다.

진정한 비OOP 패러다임이 실제로는 더 나은 대규모 솔루션을 위한 선택은 무엇입니까?아니면 요즘 들어본 적이 없는 걸까요?

저는 CS를 공부하기 시작한 이래로 이것이 궁금했습니다.OOP는 결코 능가할 수 없는 프로그래밍의 열반이라는 느낌을 받기 쉽습니다.

Answer 1

제 생각에는 OOP가 사용되는 이유는 그렇게 널리 사용되지 않아 작업에 적합한 도구가 아닙니다. 솔루션을 고객에게 이해하는 방식으로 설명 할 수 있다고 생각합니다.

자동차는 엔진이있는 차량입니다. 그것은 프로그래밍과 실제 세계입니다!

프로그래밍과 실제 세계에 매우 우아하게 맞을 수있는 모든 것을 이해하기는 어렵습니다.

Answer 2

Linux는 OOP가 아닌 대규모 프로젝트입니다. 그리고 그것으로부터 얻을 수있는 것은 많지 않을 것입니다.

OOP는 캡슐화, 데이터 숨기기, 코드 재사용, 모듈 식 ET.C와 같은 좋은 프로그래밍 관행과 관련이 있기 때문에 좋은 링을 가지고 있다고 생각합니다. 그러나 이러한 미덕은 결코 OOP에게 독특하지 않습니다.

Answer 3

Joe Armstrong이 작성한 Erlang을 살펴볼 수 있습니다.

위키 백과 :

"Erlang은 일반 목적 동시 프로그래밍 언어 및 런타임 시스템입니다. Erlang의 순차적 하위 집합은 엄격한 평가, 단일 할당 및 동적 타이핑을 갖춘 기능적 언어입니다."

조 암스트롱 :

“객체 지향 언어의 문제는 그들이 그들과 함께 가지고 다니는이 암시 적 환경을 모두 가지고 있다는 것입니다. 당신은 바나나를 원했지만 당신이 얻은 것은 바나나와 정글 전체를 들고있는 고릴라였습니다.”

Answer 4

OOP의 약속은 코드 재사용과 유지 보수가 쉬운 것이 었습니다. 나는 그것이 전달되는지 확신하지 못한다. 나는 Dot Net과 같은 것들이 우리가 다양한 공급 업체를 얻는 데 사용한 C 라이브러리와 거의 동일하다고 생각합니다. 원하는 경우 해당 코드 재사용을 호출 할 수 있습니다. 유지 보수에 관해서는 나쁜 코드는 잘못된 코드입니다. OOP는 도움이되지 않았습니다.

Answer 5

나는 OOP의 가장 큰 팬이고 매일 OOP를 연습합니다. 실제 생활과 비슷하기 때문에 코드를 작성하는 가장 자연스러운 방법입니다.

그러나 OOP의 가상화로 인해 성능 문제가 발생할 수 있습니다. 물론 이것은 당신의 디자인, 언어 및 당신이 선택한 플랫폼에 따라 다릅니다 (Java 또는 C#과 같은 쓰레기 수집 기반 언어로 작성된 시스템은 C ++로 작성된 시스템보다 더 나빠질 수 있습니다).

실시간 시스템에서 절차 적 프로그래밍이 더 적절할 수 있다고 생각합니다.

Answer 6

OOP라고 주장하는 모든 프로젝트가 실제로 OOP는 아닙니다. 때로는 코드의 대부분이 절차 적이거나 데이터 모델이 빈혈, 등등...

Answer 7

Zyx, 당신은 "대부분의 시스템은 관계형 데이터베이스를 사용합니다 ..."

그런 것이 없다는 것이 두렵습니다. 관계형 모델은 내년 40 세가 될 것이며 여전히 구현 된 적이 없습니다. "SQL 데이터베이스"라고 생각합니다. 관계형 DBM과 SQL DBMS의 차이점을 이해하려면 Fabian Pascal의 모든 것을 읽어야합니다.

"... 관계형 모델은 일반적으로 인기로 인해 선택됩니다."

사실, 그것은 인기가 있습니다.

"... 도구의 가용성,"

ALA가 필요한 주요 도구가 필요하지 않습니다 : 관계형 모델의 구현.

" 지원하다,"

예, 관계형 모델은 훌륭한 지원을 제공하지만 확실하지만 DBMS 구현에 의해 전적으로 지원되지 않습니다.

"그리고 관계형 모델이 실제로 수학적 개념이라는 사실"

그렇습니다. 수학적 개념이지만 구현되지 않으면 상아 타워로 크게 제한됩니다. 문자열 이론은 또한 수학적 개념이지만 시스템을 구현하지는 않습니다.

사실, 그것은 메망 학적 개념 임에도 불구하고 모든 과학의 첫 번째 요구 사항이 없기 때문에 (컴퓨터 과학에서와 같이) 과학이 아닙니다. 주장.

순수한 뱀 기름입니다.

"... OOP와 반대로."

OOP와는 반대로, 관계형 모델은 결코 구현되지 않았습니다.

SQL에 대한 책을 구입하고 생산성을 얻으십시오.

관계형 모델을 비생산적인 이론가들에게 맡기십시오.

Answer 8

보다 이것 그리고 이것. 분명히 5 개의 다른 프로그래밍 패러다임, 3 개의 C ++ 등 C#을 사용할 수 있습니다.

소프트웨어 구조는 기본 물리학과 유사하지 않습니다. 물리학은 새로운 실험 데이터 및/또는 이론에 의해 도전받을 수있는 패러다임을 사용하여 현실을 설명하기 위해 노력합니다. 물리학은 소프트웨어 구성이 아닌 방식으로 "진실"을 찾는 과학입니다.

소프트웨어 구성은 a입니다 사업. 당신은 할 필요가 있습니다 생산적인, 즉 누군가 돈을 지불 할 목표를 달성하기 위해. 패러다임은 유용하기 때문에 사용됩니다 효과적으로 소프트웨어를 생산합니다. 당신은 동의 할 모든 사람이 필요하지 않습니다. 내가 OOP를하고 그것이 나를 위해 잘 작동한다면, 나는 "새로운"패러다임이 그것을 배우고 돈을 배우고 나중에 전체 소프트웨어 구조를 다시 생각한다면 나에게 20% 더 유용 할 수 있을지 상관하지 않습니다. m 작업하고 처음부터 다시 디자인합니다.

또한, 당신은 또 다른 패러다임을 사용하고있을 것입니다. 그리고 나는 일본 음식 식당을 운영하는 돈을 벌 수있는 것과 같은 방식으로 여전히 행복 할 것입니다. 옆에 멕시코 푸드 레스토랑으로 돈을 벌 수 있습니다. 일본 음식이 멕시코 음식보다 나은지 여부에 대해 논의 할 필요가 없습니다.

Answer 9

나는 OOP가 곧 사라지는 것을 의심합니다. 그것은 단지 우리의 문제와 정신 모델에 너무 잘 맞습니다.

우리 가보고 시작한 것은 다중 파라디그가 접근하는 것이며, 선언적이고 기능적 아이디어가 객체 지향 디자인에 통합됩니다. 최신 JVM 언어의 대부분은 .NET 플랫폼의 LINQ 및 F#뿐만 아니라 이것 (Javafx, Scala, Clojure 등)의 좋은 예입니다.

여기에서 OO를 대체하는 것에 대해 이야기하는 것이 아니라 보완하는 것에 대해 주목하는 것이 중요합니다.

• Javafx는 선언적 솔루션이 SQL 및 XSLT를 넘어서 GUI의 시각적 구성 요소 간의 바인딩 특성 및 이벤트에도 사용할 수 있음을 보여주었습니다.

• 결함 허용 및 동시 시스템의 경우 기능 프로그래밍은 매우 Ericsson Axd301 (Erlang을 사용하여 프로그래밍)에 의해 입증 된대로 적합합니다.

따라서 ... 동시성이 더욱 중요 해지고 FP가 더 인기를 얻음에 따라이 패러다임을지지하지 않는 언어가 어려움을 겪을 것이라고 생각합니다. 여기에는 C ++, Java 및 Ruby와 같이 현재 인기있는 많은 부분이 포함되지만 JavaScript는 매우 훌륭하게 대처해야합니다.

Answer 10

OOP를 사용하면 코드 관리(새 기능 수정/업데이트/추가 등)와 이해가 더 쉬워집니다.이는 대규모 프로젝트의 경우 특히 그렇습니다.모듈/객체는 해당 데이터와 해당 데이터에 대한 작업을 캡슐화하기 때문에 기능과 큰 그림을 더 쉽게 이해할 수 있습니다.

OOP의 이점은 각각 특정 기능을 포함하는 LogManager 또는 OrderManager에 대해 (다른 개발자/관리자/고객과) 논의한 후 '파일에 데이터를 덤프하는 메소드 그룹' 및 '메서드'를 설명하는 것이 더 쉽다는 것입니다. 주문 세부정보를 추적하는 '.

따라서 OOP는 특히 대규모 프로젝트에 도움이 된다고 생각합니다. 하지만 항상 새로운 개념이 등장하므로 앞으로도 새로운 것을 계속해서 찾아보고 유용한 것을 평가하고 유지하세요.

Answer 11

사람들은 다양한 것들을 "대상"으로 생각하고 분류하는 것을 좋아합니다. 그러나 OOP가 더 큰 인기를 얻지 못한 영역이 있습니다. 대부분의 시스템은 목표보다는 관계형 데이터베이스를 사용합니다. 두 번째 기사가 주목할만한 기록을 보유하고 일부 유형의 작업에 더 나은 경우에도 관계형 모델은 인기, 도구의 가용성, 지원 및 관계형 모델이 실제로 수학적 개념이라는 사실로 인해 당연히 선택됩니다. OOP.

내가 OOP를 본 적이없는 또 다른 영역은 소프트웨어 빌딩 프로세스입니다. 모든 구성과 스크립트는 부분적으로 쉘 언어로 OOP에 대한 지원이 없기 때문에 부분적으로 OOP가 그러한 작업에 비해 너무 복잡하기 때문에 절차 적입니다.

Answer 12

약간 논란의 여지가 있는 의견이지만 적어도 현재 대중적으로 적용되는 종류의 OOP는 적합하지 않다고 생각합니다. 저것 내 특정 도메인(장면 구성 및 응용 프로그램 상태가 게임과 다소 유사한 VFX)에서 가장 큰 규모의 소프트웨어를 제작하는 데 도움이 됩니다.중소 규모에서는 매우 유용하다고 생각합니다.과거에 몇몇 몹을 초대했기 때문에 여기서는 약간 조심해야 하지만 이것이 내 특정 유형의 도메인에 대한 좁은 경험이라는 점을 인정해야 합니다.

제가 자주 발견한 어려움은 데이터를 캡슐화하는 작은 구체적인 개체가 모두 있으면 이제 서로 대화하고 싶어한다는 것입니다.그들 사이의 상호 작용은 다음과 같이 매우 복잡해질 수 있습니다(단, 수천 개의 객체에 걸쳐 있는 실제 애플리케이션에서는 훨씬 더 복잡합니다).

그리고 이것은 "상호작용 그래프"만큼 결합과 직접적으로 관련된 종속성 그래프가 아닙니다.이러한 구체적인 객체를 서로 분리하기 위한 추상화가 있을 수 있습니다. Foo 얘기 안 할 수도 있어 Bar 곧장.대신에 다음을 통해 대화할 수도 있습니다. IBar 또는 이런 종류의 것.이 그래프는 여전히 연결될 것입니다 Foo 에게 Bar 비록 분리되어 있음에도 불구하고 그들은 여전히 ​​​​서로 대화를 나누기 때문입니다.

그리고 자신의 작은 생태계를 구성하는 중소 개체 간의 이러한 모든 통신을 내 도메인의 전체 규모의 대규모 코드베이스에 적용하면 유지 관리가 극도로 어려워질 수 있습니다.그리고 부작용과 같은 객체 간의 모든 상호 작용에서 무슨 일이 일어나는지 추론하기가 어렵기 때문에 유지 관리가 너무 어려워집니다.

그 대신 내가 찾은 유용성은 전체 코드베이스를 중앙 "데이터베이스"에 액세스하는 완전히 독립적이고 무거운 하위 시스템으로 구성하는 것입니다.그런 다음 각 하위 시스템은 데이터를 입력하고 출력합니다.일부 다른 하위 시스템은 동일한 데이터에 액세스할 수 있지만 한 시스템이 서로 직접 통신하지 않을 수 있습니다.

...아니면 이거:

...그리고 각 개별 시스템은 더 이상 상태를 캡슐화하려고 시도하지 않습니다.자체 생태계가 되려고 하지 않습니다.대신 중앙 데이터베이스에서 데이터를 읽고 씁니다.

물론 각 하위 시스템을 구현할 때 이를 구현하는 데 도움이 되는 여러 개체를 사용할 수도 있습니다.그리고 이것이 바로 이러한 하위 시스템을 구현하는 데 OOP가 매우 유용하다고 생각하는 부분입니다.그러나 이러한 각 하위 시스템은 상대적으로 크지 않은 중소 규모 프로젝트를 구성하며, 중소 규모에서는 OOP가 매우 유용하다고 생각합니다.

최소한의 지식을 갖춘 "조립 라인 프로그래밍"

이를 통해 각 하위 시스템은 외부 세계에서 무슨 일이 일어나고 있는지 거의 알지 못한 채 해당 작업에만 집중할 수 있습니다.물리학에 초점을 맞춘 개발자는 물리학 하위 시스템에 앉아서 모션 구성 요소(단지 데이터)와 같은 항목을 검색하고 해당 데이터에 물리학을 적용하여 변환할 수 있는 중앙 데이터베이스가 있다는 점을 제외하고 소프트웨어 작동 방식에 대해 거의 알지 못할 수 있습니다.그리고 그것은 그의 일을 매우 단순하게 만들고 다른 모든 것이 어떻게 작동하는지에 대한 최소한의 지식으로 그가 가장 잘하는 일을 할 수 있게 만듭니다.중앙 데이터 입력 및 중앙 데이터 출력:이것이 다른 모든 것이 작동하기 위해 각 하위 시스템이 올바르게 수행해야 하는 전부입니다.이것은 내 분야에서 각 개발자가 전체 시스템 작동 방식에 대한 최소한의 지식으로 자신의 작업을 수행할 수 있는 "조립 라인 프로그래밍"에 가장 가까운 것입니다.

각 하위 시스템의 초점이 좁기 때문에 테스트도 여전히 매우 간단합니다.우리는 더 이상 특정 시스템과 관련된 최소한의 데이터를 생성하고 특정 시스템이 주어진 입력에 대해 올바른 출력을 제공하는지 테스트하는 만큼 종속성 주입을 사용하여 구체적인 객체를 조롱하지 않습니다.테스트할 시스템이 너무 적기 때문에(단지 수십 개만으로도 복잡한 소프트웨어를 구성할 수 있음) 필요한 테스트 수도 크게 줄어듭니다.

캡슐화 깨기

그런 다음 시스템은 실질적으로 서로의 존재를 인식하지 못하는 독립적인 하위 시스템을 통해 중앙 애플리케이션 상태를 변환하는 다소 평평한 파이프라인으로 변합니다.때로는 다른 시스템이 처리하는 데이터베이스에 중앙 이벤트를 푸시할 수도 있지만, 다른 시스템은 해당 이벤트가 어디서 왔는지 여전히 인식하지 못합니다.나는 이것이 적어도 내 영역에서 복잡성을 해결하는 열쇠이며 엔터티-구성 요소 시스템을 통해 효과적으로 수행된다는 것을 알았습니다.

그러나 이러한 모든 하위 시스템을 분리하고 외부 세계에 대한 최소한의 지식으로 작동하도록 하는 것은 광범위한 규모의 절차적 또는 기능적 프로그래밍에 더 가까운 것과 유사합니다. 이를 달성하고 시스템이 서로 통신할 필요를 피하기 위해 캡슐화를 깨고 있기 때문입니다. 다른.확대하면 이러한 하위 시스템 중 하나를 구현하는 데 사용되는 개체의 공유를 찾을 수 있지만 가장 넓은 규모에서 시스템은 OOP 이외의 것과 유사합니다.

글로벌 데이터

처음에는 내 분야의 건축 설계에 ECS를 적용하는 것에 대해 매우 주저했다는 점을 인정해야 합니다. 첫째, 인기 있는 상용 경쟁업체(3DS Max, SoftImage 등)에서는 이전에 ECS를 수행한 적이 없었기 때문입니다. , 이는 전 세계적으로 접근 가능한 데이터 묶음처럼 보입니다.

그러나 나는 이것이 큰 문제가 아니라는 것을 발견했습니다.우리는 여전히 불변성을 매우 효과적으로 유지할 수 있으며, 아마도 이전보다 훨씬 더 좋아질 수도 있습니다.그 이유는 ECS가 모든 것을 시스템과 구성 요소로 구성하는 방식 때문입니다.예를 들어 가장 까다로운 상황에서도 오디오 시스템은 모션 구성 요소를 변경하려고 시도하지 않으므로 안심하셔도 됩니다.팀이 제대로 조율되지 않은 경우에도 ECS가 어떤 시스템이 어떤 구성 요소에 액세스하는지 더 이상 추론할 수 없는 수준으로 저하될 가능성은 매우 낮습니다. 왜냐하면 서류상으로는 분명하고 특정 시스템이 액세스할 이유가 거의 없기 때문입니다. 부적절한 구성 요소.

반대로 이전 코드베이스에서 느슨한 조정 및 크런치 타임 하에 수행된 많은 해킹된 작업이 엑스레이 추상화를 시도하고 사물 생태계의 내부에 접근합니다.사람들이 서둘러 액세스하려는 데이터를 얻고 작업을 시도한 결과로 추상화가 누출되기 시작했습니다.그들은 기본적으로 인터페이스 디자인이 빠르게 저하되는 데이터에 액세스하려고 시도하고 있었습니다.

특정 유형의 구성요소를 수정하는 시스템이 단 하나뿐인 경우가 많기 때문에(일부 예외적인 경우에는 2개) 시스템이 구성되는 방식으로 인해 여전히 캡슐화와 모호하게 유사한 점이 있습니다.그러나 그들은 해당 데이터를 소유하지 않으며 해당 데이터를 검색하는 기능을 제공하지 않습니다.시스템은 서로 대화하지 않습니다.이들은 모두 중앙 ECS 데이터베이스(이러한 모든 시스템에 주입되어야 하는 유일한 종속성)를 통해 작동합니다.

유연성과 확장성

이것은 이미 엔티티 구성 요소 시스템에 대한 외부 자원에서 널리 논의되어 있지만, 포유 동물, 곤충 및 식물 인 생물에 대한 제안과 같은 개념을 돋보이게하는 아이디어에 근본적으로 새로운 디자인 아이디어에 적응하는 데 매우 유연합니다. 콩나물은 한 번에 햇빛 아래에서 잎을 잎으로 둡니다.

그 이유 중 하나는 깨뜨릴 중심 추상화가 없기 때문입니다.이를 위해 더 많은 데이터가 필요하거나 식물, 포유류 및 곤충에 필요한 구성 요소를 함께 묶는 엔터티를 만드는 경우 몇 가지 새로운 구성 요소를 도입합니다.곤충, 포유류 및 식물 구성 요소를 처리하도록 설계된 시스템은 자동으로 이를 선택하고 새로운 구성 요소 콤보로 엔터티를 인스턴스화하기 위해 코드 줄을 추가하는 것 외에 아무것도 변경하지 않고도 원하는 동작을 얻을 수 있습니다.완전히 새로운 기능이 필요한 경우 새 시스템을 추가하거나 기존 시스템을 수정하면 됩니다.

다른 곳에서 많이 논의되지 않은 것은 우리가 예상하지 못한 개념을 깨뜨리는 설계 변경이 없는 시나리오에서도 유지 관리가 얼마나 쉬워지는가입니다.ECS의 유연성을 무시하더라도 코드베이스가 특정 규모에 도달하면 작업을 정말 단순화할 수 있습니다.

객체를 데이터로 전환

위의 첫 번째 그래프에 더 가까운 코드베이스를 유지하는 것이 어렵다는 것을 본 OOP가 많은 이전 코드베이스에서는 필요한 코드의 양이 폭발적으로 늘어났습니다. Car 이 다이어그램에서:

...여러 인터페이스를 구현하는 완전히 별도의 하위 유형(클래스)으로 구축되어야 했습니다.그래서 우리는 시스템에 폭발적인 수의 개체를 갖게 되었습니다.방향 조명의 포인트 라이트에 대한 별도의 객체, 다른 객체의 어안 카메라에 대한 별도의 객체 등끝없는 조합으로 수십 개의 추상 인터페이스를 구현하는 수천 개의 개체가 있었습니다.

ECS와 비교했을 때 수백 개만 필요했고 코드의 작은 부분을 사용하기 전에도 정확히 동일한 작업을 수행할 수 있었습니다. Car 더 이상 클래스가 필요하지 않은 것으로 엔터티가 됩니다.단 하나의 일반화된 인스턴스로서 구성 요소 데이터의 간단한 컬렉션으로 변합니다. Entity 유형.

OOP 대안

따라서 설계의 가장 광범위한 수준에서 OOP를 과도하게 적용하면 유지 관리성이 실제로 저하될 수 있는 경우가 있습니다.시스템의 가장 넓은 조감도에서 시스템을 평면화하고 객체와 상호 작용하는 객체와 상호 작용하는 객체를 너무 "깊게" 모델링하려고 시도하지 않는 데 도움이 될 수 있습니다.

과거에 작업한 두 시스템과 현재 작업한 시스템을 비교해 보면 새 시스템은 기능이 더 많지만 수십만 LOC가 필요합니다.전자에는 2천만 개 이상의 LOC가 필요했습니다.물론 이전 시스템이 엄청난 유산을 갖고 있기 때문에 가장 공정한 비교는 아니지만, 레거시 수하물 없이 기능적으로 상당히 동일한 두 시스템의 일부를 선택하면(적어도 우리가 얻을 수 있는 것과 거의 동일합니다) ECS는 동일한 작업을 수행하기 위해 코드의 작은 부분을 사용하며, 부분적으로는 클래스를 대신 처리하기 위한 대용량 시스템을 사용하여 원시 데이터(구성 요소)의 컬렉션(엔티티)으로 변환하여 시스템에 있는 클래스 수를 극적으로 줄이기 때문입니다. 소형/중형 물체의 보트로드.

진정으로 비 루프 패러다임이 실제로 큰 솔루션을위한 더 나은 선택 인 시나리오가 있습니까?아니면 요즘 들어 본 적이 없습니까?

들어 본 적이 없습니다.예를 들어 위에서 설명하는 시스템은 게임에서 널리 사용됩니다.내 분야에서는 매우 드물지만(내 분야의 아키텍처 대부분은 순수한 인터페이스를 갖춘 COM과 유사하며 과거에 작업한 아키텍처 유형이기도 합니다), 게이머가 언제 무엇을 하는지 자세히 살펴보는 것을 발견했습니다. 아키텍처를 설계하면 성장하고 성장하는 과정에서 여전히 매우 이해하기 쉬운 무언가를 만들 수 있다는 점에서 세상이 달라졌습니다.

즉, 일부 사람들은 ECS를 그 자체로 일종의 객체 지향 프로그래밍으로 간주합니다.그렇다면 데이터(구성 요소 및 이를 구성하는 엔터티)와 기능(시스템)이 분리되어 있기 때문에 우리 대부분이 생각하는 종류의 OOP와 유사하지 않습니다.OOP의 가장 기본적인 측면 중 하나로 간주되는 광범위한 시스템 수준에서 캡슐화를 포기해야 합니다.

고급 코딩

그러나 보통 더 높은 수준의 솔루션은 거의 항상 OOP 방식으로 구성되는 것 같습니다.

매우 높은 수준의 코드로 애플리케이션을 통합할 수 있다면 팀이 유지 관리해야 하는 코드에 따라 규모가 다소 작거나 중간인 경향이 있으며 OOP를 사용하여 매우 효과적으로 어셈블할 수 있습니다.

내 VFX 분야에서는 광선 추적, 이미지 처리, 메시 처리, 유체 역학 등과 같이 상대적으로 낮은 수준의 작업을 수행해야 하는 경우가 많으며 실제로 경쟁하고 있기 때문에 타사 제품에서 이러한 작업을 통합할 수 없습니다. 낮은 수준에서 수행할 수 있는 작업에 대해 더 많은 정보를 제공합니다(사용자는 더 멋진 GUI보다 최첨단의 경쟁력 있는 프로덕션 렌더링 개선에 더 열광합니다).따라서 비트와 바이트의 매우 낮은 수준 셔플링부터 스크립터가 내장된 스크립팅 언어를 통해 작성하는 매우 높은 수준의 코드에 이르기까지 매우 많은 코드가 있을 수 있습니다.

소통의 인터웹

그러나 모든 유형의 애플리케이션(고수준, 저수준 또는 콤보)에 대해 충분히 큰 규모를 갖춘 지점이 있으며, 모든 것을 캡슐화하려고 시도하는 것이 더 이상 유용하지 않은 매우 복잡한 중앙 애플리케이션 상태를 중심으로 회전합니다. 사물로.그렇게 하면 모든 것 사이에서 진행되는 상호 작용의 양이 늘어나서 무슨 일이 일어나고 있는지 추론하기가 복잡해지고 어려워지는 경향이 있습니다.서로 대화해야 하는 캡슐화된 생태계로 각 항목을 모델링하는 것을 중단하는 충분히 큰 규모의 한계점이 없다면 수천 개의 생태계가 서로 대화하는 것에 대해 추론하는 것이 더 이상 쉽지 않습니다.각각이 개별적으로 단순하더라도 전체적으로 고려한 모든 것이 마음을 압도하는 것 이상으로 시작될 수 있으며, 변경하고 새로운 기능을 추가하고 디버깅하는 등의 작업을 수행하기 위해 많은 부분을 고려해야 하는 경우가 많습니다. OOP 원칙을 중심으로 전체 대규모 시스템의 디자인을 회전시키려고 노력하십시오.적어도 일부 도메인에 대해 어느 정도 규모로 캡슐화를 해제하는 데 도움이 될 수 있습니다.

그 시점에서는 물리 시스템이 자체 데이터를 캡슐화하도록 하는 것이 더 이상 그다지 유용하지 않습니다(그렇지 않으면 많은 것들이 물리 시스템과 대화하고 해당 데이터를 검색하고 적절한 입력 데이터로 초기화하기를 원할 수 있습니다). 나는 ECS를 통해 이 대안이 매우 유용하다는 것을 알았습니다. 왜냐하면 그것이 유추 물리학 시스템과 모든 무거운 시스템을 "중앙 데이터베이스 변환기" 또는 "뭔가 새로운 것을 출력하는 중앙 데이터베이스 리더"로 바꿔서 이제 서로에 대해 인식할 수 없기 때문입니다.그러면 각 시스템은 매우 복잡한 통신 그래프에서 노드를 형성하는 개체라기보다는 평평한 파이프라인의 프로세스와 더 유사해지기 시작합니다.