2008-09-11 3 views
1

다양한 유형의 많은 항목으로 구성된 시스템 모델을 빌드하는 일반적인 해결책은 각 모듈이 특정 유형을 담당하는 모듈 시스템을 만드는 것입니다. 예를 들어, wombats WombatModule : IModule 용 모듈이있을 것입니다. 여기서 IModule 인터페이스는 GetCount() (wombats 수 찾기)와 Update() (모든 wombats 상태 업데이트)와 같은 메소드를 가지고 있습니다.모델링을위한 아키텍처

더 많은 객체 지향 접근법은 모든 항목 유형에 대해 클래스를 갖고 모든 항목에 대한 인스턴스를 만드는 것입니다. 그러면 Wombat 클래스가 생성됩니다 (Update()와 같은 메소드를 사용하여이 하나의 wombat를 업데이트하십시오).

코드 관점의 차이는 무시할 만하지만 런타임은 크게 다릅니다. 모듈 지향 솔루션은 확실히 빠릅니다. 객체 생성이 적고 모든 wombats에 공통적 인 작업을보다 쉽게 ​​최적화 할 수 있습니다.

유형 및 모듈 수가 증가하면 문제가 발생합니다. 각 모듈이 여러 항목 만 지원하거나 모듈의 복잡성이 증가하여 하나의 일반적인 유형 (예 : 뚱뚱하고 날씬한 웜뱃)의 항목이 약간 다르기 때문에 대부분의 성능 이점을 잃게됩니다. 아니면 둘다.

모든 WombatModule이 숨겨진 Wombat 객체 컬렉션을 유지하고 루프에서 해당 메소드를 실행할 때 성능이 떨어지는 것으로 나타났습니다.

성능이 장기적인 개발보다 문제가 적 으면 항목 별 개체 대신 모듈을 사용하는 아키텍처상의 이유를 식별 할 수 있습니까? 내가 놓친 또 다른 가능성이있을 수 있습니까?

답변

1

나는 embedded software company에 근무하고 우리의 code base은 상당히 큽니다. 코드베이스는 특정 기능을 수행하고 일부 객체를 유지 관리하는 모듈로 설계되었습니다. 일부 객체는 독립 객체로 존재합니다. 우리의 접근법에서 볼 수있는 가장 큰 문제는 모듈의 경계를 구별하는 것입니다. 우리 모듈은 시간이 지남에 따라 불필요하게 복잡 해지는 경향이 있으며 원래는 경계를 벗어난 기능을 수행하기 위해 천천히 성장합니다. 내가 취해야 할 최선의 방향은 모듈 방식으로 설계하고 매우 구체적인 객체를 구현하고 모듈이 의도 한 것보다 크게 성장하지 못하도록하기위한 노력이라고 말할 수 있습니다.