"Composition Hierarchy"가 중요하지 않다면 사과하지만 질문에서 그 의미가 무엇인지 설명하겠습니다.
"상속 계층 구조 유지"또는 "상속보다 컴포지션 선호"등의 변형을 경험하지 않은 OO 프로그래머는 없습니다. 그러나 심층 구성 계층도 문제가있는 것 같습니다.
실험 결과를 자세히 설명하는 보고서 모음이 필요하다고 가정 해 보겠습니다.
class Model {
// ... interface
Array<Result> m_results;
}
각 결과에는 특정 속성이 있습니다. 여기에는 실험 시간과 실험의 각 단계에서 얻은 일부 메타 데이터가 포함됩니다.
enum Stage {
Pre = 1,
Post
};
class Result {
// ... interface
Epoch m_epoch;
Map<Stage, ExperimentModules> m_modules;
}
큰 확인. 이제 각 실험 모듈에는 실험 결과를 설명하는 문자열과 실험 샘플 세트에 대한 참조 모음이 있습니다.
class ExperimentalModules {
// ... interface
String m_reportText;
Array<Sample> m_entities;
}
그리고 각 샘플에는 ... 글쎄요, 당신은 그림을 얻습니다.
문제는 응용 프로그램 도메인에서 객체를 모델링하는 경우 매우 자연스러운 것처럼 보이지만 하루가 끝나면 Result바보 같은 데이터 컨테이너입니다! 큰 클래스 그룹을 만드는 것은 가치가없는 것 같습니다.
위에 표시된 데이터 구조와 클래스가 응용 프로그램 도메인의 관계를 올바르게 모델링한다고 가정하면 심층적 인 구성 계층에 의존하지 않고 이러한 "결과"를 모델링하는 더 좋은 방법이 있습니까? 그러한 디자인이 좋은지 아닌지를 결정하는 데 도움이되는 외부 컨텍스트가 있습니까?
외부 문맥 부분을 이해하지 마십시오.
—
Tulains Córdova에서
@ TulainsCórdova 제가 여기서 묻고 자하는 것은 "심층 구성이 좋은 솔루션 인 상황이 있습니까?"입니다.
—
AwesomeSauce
나는 대답을 추가했다.
—
Tulains Córdova
예, 정확히 상속을 컴포지션으로 대체하여 사람들이 고치려고하는 문제는 하나의 기능 집계 전략을 다른 것으로 집계했다고해서 마술처럼 사라지지 않습니다. 둘 다 복잡성을 관리하는 솔루션이며 복잡성은 여전히 존재하며 어떤 방식 으로든 처리해야합니다.
—
메이슨 휠러
심층 데이터 모델에는 문제가 없습니다. 그러나 각 계층에서 1 : N 관계이기 때문에 상속으로 모델링 할 수있는 방법을 보지 못했습니다.
—
usr