OO 디자인 질문 — 부모/자식 — 순환?

StackOverflow https://stackoverflow.com/questions/1028965

문제

저는 OO 디자인 프로세스에 상당히 익숙하지 않으므로 양해해 주시기 바랍니다....

클래스로 모델링해야 하는 두 개의 엔터티가 있습니다. 이를 부모와 자식이라고 합니다(실제 문제 도메인에 충분히 가깝습니다).한 부모는 한 명 이상의 자녀를 갖게 됩니다. 이 응용 프로그램에서는 자녀가 없는 부모에게는 관심이 없습니다.

내 두뇌가 점심을 먹으러 나가는 곳은 다른 것 중에서 하나를 찾을 수 있어야 한다는 사실입니다.내 데이터베이스에서는 일반적인 외래 키 관계를 사용하여 이를 구현할 수 있으며 SQL의 집합 기반 특성을 통해 특정 부모에 대한 모든 하위 항목 또는 특정 하위 항목에 대한 상위 항목을 쉽게 찾을 수 있습니다.그런데 물건으로...?

나 생각하다 부모는 자식의 컬렉션(목록 등)을 가지고 있어야 합니다.나는 또한 각 자식이 부모에 대한 참조를 가지고 있어야 한다고 생각합니다.그러나 참조의 순환적 성격이 머리를 아프게 합니다.

나는:

  • 올바른 길을 가고 있나요?
  • 완전히 기지에서 벗어났나요?그렇다면 어떻게 다르게 해야 합니까?

이는 거의 확실하게 VB.NET에서 구현될 것이지만 아직 코드를 자르려면 아직 멀었습니다.

8개 답변 후 편집:

모두 감사합니다.받아들일 수 있는 답변을 하나만 고르는 것은 어려웠습니다.

답변에서 의문이 제기된 몇 가지 사항을 명확히 하려면 다음을 수행하십시오.

  • 부모와 자녀는 매우 다른 실체입니다. 상속 관계는 전혀 없습니다.나는 그들이 실제 문제 영역에 매우 가깝기 때문에 내가 한 이름을 선택했고, 이제 그것이 OO 관점에서 혼란의 원천임을 알았습니다.
  • 계층 구조는 단지 한 수준의 깊이에 불과합니다. 어린이는 신청서에 자녀가 없습니다.

다시 한 번 감사드립니다.

도움이 되었습니까?

해결책

원형 참조는 트리 구조를 만들 때 괜찮고 절대적으로 표준입니다. 예를 들어, HTML의 문서 개체 모델 (DOM)에는 모든 것에 대한 부모 및 자식 속성이 있습니다. 마디 돔 트리에서 :

interface Node {
    // ...
    readonly attribute Node     parentNode;
    readonly attribute NodeList childNodes;
    // ...
}

다른 팁

당신이 나에게 올바른 길을 가고있는 것 같습니다.도메인 모델에 따라 부모에게는 자녀가 있고 자녀에게는 부모가 있습니다.서로 참조해야 할 수도 있습니다.

순환 참조에는 아무런 문제가 없습니다. 단지 순환 참조를 사용하여 수행할 작업에 주의해야 합니다.문제가 발생하는 부분은 데이터베이스에서 엔터티를 로드할 때 자동화된 방식으로 서버 측에서 엔터티를 관리하는 것입니다.예를 들어 쿼리를 사용하여 데이터베이스에서 Child 개체를 가져옵니다.부모 정보를 포함하나요?부모의 자녀도 포함되나요?

Lightspeed나 Microsoft의 Entity Framework와 같은 ORM 도구는 일반적으로 "지연 로딩" 지시문을 사용하여 이를 처리합니다.그들은 처음에 필요한 것을 가져올 것입니다(따라서 Child를 가져올 때 Child 속성과 부모 ID만 가져옵니다).나중에 Parent를 역참조하면 Parent 속성을 가져와서 Parent 개체를 인스턴스화합니다.나중에 여전히 Children 컬렉션에 액세스하면 관련 하위 정보를 가져오고 해당 컬렉션에 대한 Child 개체를 만듭니다.하지만 필요할 때까지는 채워지지 않습니다.

이런 식으로 객체 그래프를 가로 지르는 것이 합리적이라고 생각합니다. 게시물에서 정당한 이유가 있는지 알기는 어렵지만, 그 자체로 참조가 나쁜 디자인을 증명하지는 않습니다.

나는 당신이 올바른 길을 가고 있다고 믿습니다. 참조의 원형 특성이 머리를 아프게하는 이유는 무엇입니까? 당신이 겪고있는 근본적인 문제는 무엇입니까? Parent 자녀들에 대한 언급, a Child 부모에 대한 언급이 있습니까?

부모 수업이 자식 수업에 대해 알고있는 클래스 계층 구조에 대해 이야기하고 있습니까?

모든 비용으로 이것을 피해야합니다.

기본적으로 아동 수업은 부모 수업에 대해 모두 알고 있습니다. 부모 클래스의 인스턴스이기 때문입니다. 그러나 부모 수업에 아동 수업에 대해 알게 되려면 아동 수업이 다른 모든 어린이 수업에 대해 모두 알고 있어야합니다. 이것은 한 자녀와 해당 수업의 다른 모든 자녀 사이에 의존성을 만듭니다. 이것은 인재 할 수없는 시나리오입니다 ~ 할 것이다 미래에 문제를 일으키기 때문에 - 컴파일 또는 실행을 할 수 있다면 많은 언어로는 그렇지 않습니다.

즉, 클래스 계층 구조를 시도하지 않고 수집 계층, 즉 트리를하려고하는 것처럼 들립니다. 이 경우 예, 당신은 올바른 길을 가고 있습니다. 일반적인 패러다임입니다. 상위 노드에는 자식 노드 모음이 있으며, 하위 노드에는 상위 노드를 참조합니다.

문제는? 그것들입니다 모두 같은 클래스! C#의 매우 간단한 예는 다음과 같습니다.

public class Node
{
  public readonly Node Parent; // null Parent indicates root node
  public readonly List<Node> Children = new List<Node>();
  public Node(Node parent)
  {
     Parent = parent;
  }
  public Node()
  {
     parent = null;
  }
  public void AddChild(Node node)
  {
     Children.Add(node);
  }
}

나는 이것이 당신이 정말로 당신의 후에 있다는 느낌이 듭니다. 이 패러다임을 사용하면 사악한 목적을 위해 하위 클래스 노드를 사용합니다.

P의 객체에 어린이를 나타내는 객체 P-> C [] 배열이 포함되어 있음을 이해하면 이해합니다. 그리고 자녀가없는 노드 P는 잎입니다 ... 각 p는 p-> p '(부모)를 포함합니다.

당신이 지정한 솔루션, 부모가 자녀에 대한 언급을 포함하고 그 반대도 마찬가지입니다. 이것은 실제로 모든 종류의 링크를 수행하고 알고리즘을 수행하여이를 교체하고 열거 할 수있는 트리 일뿐입니다. 괜찮아!

나는 나무 챕터를 읽는 것이 좋습니다 컴퓨터 프로그래밍의 기술 나무 구조와 부모와 어린이를 열거하는 효율적인 방법을 탁월하고 심도있게 살펴보십시오.

아이들이라면 ~ 해야 하다 부모가 있으면 보통 아동 생성자에 부모 유형 인스턴스가 필요합니다.

당신이 나쁜 디자인으로가는 길에있는 것처럼 들립니다. 당신의 아키텍처에는 원형 참조가 없어야합니다.

자녀가 왜 부모에 대한 참조가 필요한지, 그 반대도 마찬가지입니다. 나는 자녀 모음을 가진 부모에게 몸을 기울일 것입니다. 그런 다음 부모에게 기능을 추가하여 자식 객체가 인스턴스의 자녀인지 확인할 수 있습니다.

목표에 대한 더 나은 설명도 조금 더 도움이 될 수 있습니다 ...

편집하다

나는 조금 더 읽고 (그리고 의견을 들었습니다) ... 그리고 그것은 내가 꽤 잘못된 것으로 밝혀졌습니다. 원형 참조는 실제로 당신이 그들에게 조심하고 그들이 손을 떼지 못하게하는 한 그들의 자리를 차지합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top