존재 대 구성

존재 대 구성 [닫힘]

---

UML에서 구성과 구별의 차이점을 이해하는 데 어려움을 겪습니다. 누군가 나에게 그들 사이의 좋은 비교와 대조를 제공 할 수 있습니까? 또한 코드에서 이들의 차이점을 인식하는 방법을 배우고 / 또는 간단한 소프트웨어 / 코드 예제를보고 싶습니다.

편집 : 내가 많은 이유 중 일부는 우리가 직장에서하는 역 문서화 활동 때문입니다. 코드를 작성했지만 돌아가서 코드에 대한 클래스 다이어그램을 통과합니다. 우리는 연관성을 갖고 있고 싶습니다.

---

거기와 구성의 차이는 거기에 따라 달라집니다.

다른 답변에 언급 된 자동차의 예를 들어 보겠습니다. 예, 자동차 배기 가스가 "자체적으로"서있을 수 있으므로 자동차와 구성되지 않을 것입니다. 독립형 자동차 배기 가스를 처리해야하는 애플리케이션 (자동차 매장 관리 애플리케이션?)을 빌드하는 경우 내장가 선택이 될 것입니다. 그러나 이것은 단순한 레이싱 게임이고 자동차 배기 가스가 자동차의 일부로 만 사용 수준은 꽤 괜찮을 것입니다.

체스 판? 같은 문제입니다. 특정 응용 프로그램에서만 체스 판 없이는 체스 말이 존재하지 않습니다. 다른 것 (장난감 체스와 같은)에서는 체스 말이 체스 판으로 구성 될 수 없습니다.

구성은 더욱 악화됩니다. 일부 언어에서는 차이를 쉽게 알아 차릴 수 있습니다 ( "참조로"대 "가치로", 단순 할 때) 다른 언어에서는 전혀 존재하지 않을 수 있습니다.

그리고 마지막 조언은? 이 문제에 너무 많은 시간을 사용할 수 없습니다. 그럴 가치가 없습니다. 구분은 실제로 거의 유용하지 않습니다. (완전히 명확한 "구성"이 있더라도 캐싱과 같은 것들이 있기 때문에 구현할 수 있음).

---

경험상 :

class Person {
    private Heart heart;
    private List<Hand> hands;
}

class City {
    private List<Tree> trees;
    private List<Car> cars
}

구성 (사람, 심장, 손)에서 "하위 개체"(하트, 손)는 사람이 즉시 파괴됩니다.

집합 (City, Tree, Car)에서 "하위 개체"(Tree, Car)는 City가 파괴 될 때 파괴되지 않습니다.

결론은 컴포지션이 상호 존재를 강조하고, 속성이 필요하지 않다는 것입니다.

---

구성 및 재고는 연결 유형입니다. 광범위하게 언어 언어 프로그래밍에서 큰 차이가 있습니다. 이 둘의 차이점을 Java 코드 예제로 설명하려고 노력할 것입니다.

Aggregation : 객체가 다른 객체 외부에 존재하고 외부에 생성되어 생성자에게 인수 (예 :)로 전달됩니다. 예 : 사람 – 자동차. 자동차는 다른 생성에서 생성되는 다음 사람 속성이됩니다.

// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer(HttpListener listener, RequestProcessor processor) {
    this.listener = listener;
    this.processor = processor;
  }
}

구성 : 객체는 다른 것의 일부로서 존재하거나 다른 것의 내부에서만 의미가 있습니다. 예 : 사람 – 마음. 당신은 마음을 만들어서 사람에게 전달하지 않습니다.

// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer() {
    this.listener = new HttpListener(80);
    this.processor = new RequestProcessor(“/www/root”);
  }
}

여기에 집계와 구성의 차이점 예를 설명했습니다.

---

컴포지션은 자식 개체가 부모와 수명을 공유 함을 의미합니다. 집계는 그렇지 않습니다. 예를 들어, 체스 판은 체스 스퀘어로 구성되어 있습니다. 체스 스퀘어는 보드 없이는 실제로 존재하지 않습니다. 그러나 자동차는 부품의 집합체입니다. 자동차 배기 가스는 당시 자동차의 일부가 아니라면 여전히 자동차 배기 가스입니다.

---

The example I learned was fingers to the hand. Your hand is composed of fingers. It owns them. If the hand dies, the fingers die. You can't "aggregate" fingers. You can't just go grab extra fingers and attach and detach them from your hand at will.

디자인 관점에서 볼 때 여기의 가치는 다른 포스터가 말했듯이 종종 물체 수명과 관련이 있습니다. 고객이 있고 계정이 있다고 가정합니다. 해당 계정은 고객의 "구성된"개체입니다 (적어도 대부분의 컨텍스트에서 생각할 수 있음). 고객을 삭제하면 계정 자체에 가치가 없으므로 삭제됩니다. 그 반대는 종종 객체 생성에 적용됩니다. 계정은 고객의 맥락에서만 의미를 갖기 때문에 고객 생성의 일부로 계정 생성이 발생합니다 (또는 느리게 수행하는 경우 일부 고객 거래의 일부가 됨).

디자인에서 어떤 개체가 다른 개체를 소유 (구성)하는지와 다른 개체를 참조 (집계)하는 개체에 대해 생각하는 것이 유용합니다. 개체 생성 / 정리 / 업데이트에 대한 책임이 어디에 있는지 확인하는 데 도움이 될 수 있습니다.

코드에 관해서는 종종 말하기가 어렵습니다. 코드의 대부분은 개체 참조이므로 참조 된 개체가 구성 (소유)인지 집계되었는지 여부가 명확하지 않을 수 있습니다.

---

사이의 차이점에 대해 존재 얼마나 많은 혼란이 놀라운 부분 - 전체 - 협회 개념 응집 및 구성 . 주된 문제는 구성의 개념이 전체 없이는 부분이 존재할 수 없도록 전체와 부분 사이의 수명주기 종속성을 암시한다는 광범위한 오해 (전문 소프트웨어 개발자 및 UML 작성자 사이에서도)입니다. 그러나이 견해는 공유 할 수없는 부분과 부분-전체-연관이있는 경우도 있다는 사실을 무시하고 부분이 전체의 파괴에서 분리되어 살아남을 수 있습니다.

UML 사양 문서에서 "구성"이라는 용어의 정의는 항상 공유 할 수없는 부분을 의미했지만 "구성"의 정의 특성이 무엇인지, 그리고 단순히 선택적 특성이 무엇인지는 명확하지 않습니다. 새 버전 (2015 년 현재)에서도 UML 2.5는 "구성"이라는 용어의 정의를 개선하려는 시도 후에도 여전히 모호한 상태로 남아 있으며 비와 부분 전체 연결을 모델링하는 방법에 대한 지침을 제공하지 않습니다. 부분이 분리 될 수없고 전체가 함께 파괴되는 경우와는 반대로 부분이 분리 될 수 있고 전체가 파괴 되어도 살아남을 수있는 공유 가능한 부분. 그들은 말한다

복합 객체가 삭제되면 객체 인 모든 부품 인스턴스도 함께 삭제됩니다.

그러나 동시에 그들은 또한 말합니다

부품 객체는 복합 객체가 삭제되기 전에 복합 객체에서 제거 될 수 있으므로 복합 객체의 일부로 삭제되지 않습니다.

이러한 혼동은 UML 정의가 불완전 함을 나타내며, 이는 컴포넌트와 컴포지트 간의 라이프 사이클 종속성을 고려하지 않습니다. 따라서 컴포넌트를 컴포지트에서 분리 할 수 ​​없으므로 컴포지트가 파괴 될 때마다 소멸되어야 하는 << 분리 불가 >> 컴포지션에 대한 UML 스테레오 타입을 도입하여 UML 정의를 향상시킬 수있는 방법을 이해하는 것이 중요합니다 .

1) 구성

마찬가지로 마틴 파울러 설명했다 , 조성물의 특성의 주된 문제는 "오브젝트는 하나 개의 구성 관계의 일부분 일 수있다"이다. 이것은 Geert Bellekens 의 우수한 블로그 게시물 UML Composition vs Aggregation vs Association 에서도 설명됩니다 . 컴포지션의 이러한 정의 특성 ( 배타적 또는 공유 불가능한 부분 포함) 외에도 컴포지션에는 컴포지션과 해당 구성 요소 간의 수명주기 종속성이있을 수 있습니다. 실제로 이러한 종속성에는 두 가지 종류가 있습니다.

1. 컴포넌트 가 항상 컴포지트에 연결 되어야하는 경우, 즉 컴포지션 라인의 컴포지트 측면에서 "정확히 1"다중성으로 표현되는 필수 컴포지트 가있는 경우에는 다시 사용해야합니다. 다른 컴포지트에 (또는 다시 연결) 현재 컴포지트가 파괴되면 파괴됩니다. 이는 아래 다이어그램 Person과 같이과 사이의 구성으로 예시됩니다 Heart. 심장은 소유자가 사망했을 때 파괴되거나 다른 사람에게 이식됩니다.
2. 컴퍼넌트마다 분리 될 수없는 것이있다 환언의 복합체, 또는,로부터 분리 하고, 단지 그 다음, 구성 요소는 복합체가 파괴 될 때, 폐기되어야한다. 분리 부와 같은 조성물의 일례의 조성물 Person및 Brain.

요약하면 수명주기 종속성은 특정 구성 사례에만 적용되지만 일반적으로는 적용되지 않으므로 정의되는 특성이 아닙니다.

UML 사양에는 "복합 인스턴스가 삭제되기 전에 복합 인스턴스에서 부품이 제거 될 수 있으므로 복합 인스턴스의 일부로 삭제되지 않을 수 있습니다."라고 명시되어 있습니다. Car- Engine구성 의 예 에서 다음 다이어그램과 같이 자동차가 파괴되기 전에 엔진을 자동차에서 분리 할 수있는 경우가 분명합니다.이 경우 엔진이 파괴되지 않고 재사용 할 수 있습니다. 이것은 컴포지션 라인의 합성 측면에서 0 또는 1의 다중성을 의미합니다.

다중 복합 측의 조성물의 연결 단부 중 어느 하나 또는 0..1이고, 필수 성분은 합성이 있으면 사실에 따라 (a 복합체에 부착되어야한다) 여부. 구성 요소가 분리 불가능한 경우 이는 필수 구성 요소가 있음을 의미합니다.

2) 집계

집계는 전체의 일부를 다른 전체와 공유 할 수있는 부분-전체-관계의 의도 된 의미와 관련된 또 다른 특수한 형태의 연관입니다. 예를 들어, 다음 다이어그램에 표시된대로 클래스 DegreeProgram와 의 집계를 모델링 할 수 있습니다 Course. 코스는 학위 프로그램의 일부이고 코스는 둘 이상의 학위 프로그램간에 공유 될 수 있습니다 (예 : 공학 학위는 C를 공유 할 수 있음). 컴퓨터 과학 학위가있는 프로그래밍 과정).

그러나 공유 가능한 부분 이 있는 집계의 개념은 실제로 그다지 의미가 없으므로 구현에 아무런 영향을 미치지 않으므로 많은 개발자가 클래스 다이어그램에서 흰색 다이아몬드를 사용하지 않고 단순한 연관성을 모델링하는 것을 선호합니다. 대신. UML 사양은 "공유 집계의 정확한 의미는 애플리케이션 영역과 모델러에 따라 다릅니다"라고 말합니다.

다수 전체 측 집합체의 연관 단부는 임의의 수 (*) 일부에 속하거나 할 수 있기 때문에 수있다 공유 wholes의 임의의 수 중에서.

---

코드 측면에서 컴포지션은 일반적으로 포함하는 개체가 구성 요소 *의 인스턴스를 생성하는 책임이 있고 포함하는 개체가 이에 대한 유일한 장기 참조를 보유하고 있음을 나타냅니다. 따라서 부모 객체가 역 참조되고 가비지 수집되면 자식도 마찬가지입니다.

그래서이 코드는 ...

Class Order
   private Collection<LineItem> items;
   ...
   void addOrderLine(Item sku, int quantity){
         items.add(new LineItem(sku, quantity));
   }
}

LineItem이 주문의 구성 요소임을 암시합니다. LineItem은 포함 된 주문 외부에 존재하지 않습니다. 그러나 Item 객체는 순서대로 구성되지 않습니다. 필요에 따라 전달되며 상점에 주문이 없더라도 계속 존재합니다. 구성 요소가 아니라 연관되어 있습니다.

* nb 컨테이너는 구성 요소를 인스턴스화하는 역할 을하지만 실제로 new ... () 자체를 호출하지 않을 수 있습니다. 이것은 Java이므로 일반적으로 먼저 처리 할 팩토리가 한두 개 있습니다!

---

다른 답변에 제공된 개념적 일러스트레이션은 유용하지만 도움이 된 또 다른 요점을 공유하고 싶습니다.

나는 코드 생성을위한 UML, 소스 코드를위한 UML 또는 관계형 데이터베이스를위한 DDL에서 약간의 마일리지를 얻었습니다. 거기에서, 나는 테이블에 널 불가능한 외래 키 (데이터베이스에 있음)와 널 불가능한 "부모"(그리고 종종 "최종") 객체가 있음을 나타 내기 위해 구성을 사용했습니다. 레코드 또는 개체가 "고아"로 존재하거나 부모 개체에 연결되지 않거나 다른 부모 개체에 의해 "채택"될 수 있도록 집계를 사용합니다.

즉, 모델에 대한 코드를 작성할 때 필요할 수있는 몇 가지 추가 제약을 암시하기 위해 컴포지션 표기법을 속기로 사용했습니다.

---

내가 좋아하는 예 : 구성 : 물은 연못 의 일부 입니다. (연못은 물의 구성입니다.) 집합 : 연못 에는 오리와 물고기가 있습니다 (연못 에는 오리와 물고기가 집합합니다)

보시다시피 저는 "part-of"와 "has"를 굵게 표시했습니다.이 두 구문은 일반적으로 클래스간에 어떤 종류의 연결이 있는지를 가리킬 수 있기 때문입니다.

그러나 다른 사람들이 지적했듯이 연결이 컴포지션인지 집계인지는 애플리케이션에 따라 여러 번 다릅니다.

---

집계 관계와 복합 관계를 구분하는 것은 너무 어렵지만 몇 가지 예를 들어 보겠습니다. 집과 방이 있고 여기에 복합 관계가 있고 방은 집의 일부이며 방 생활이 시작되었습니다. 집 생활이 끝나고 Will은 집 생활이 끝날 때 끝납니다. 방은 집의 일부입니다. 우리는 국가와 수도, 책 및 페이지와 같은 구성에 대해 이야기합니다. 종합적인 관계의 예를 들어, 팀과 플레이어를 예로 들어, 플레이어는 팀없이 존재할 수 있고, 팀은 플레이어 그룹이며, 플레이어 생활은 팀 생활 이전에 시작할 수 있습니다. 프로그래밍에 대해 이야기하면 플레이어를 만들 수 있고 팀을 만들 것입니다. 그러나 컴포지션 아니오를 위해 우리는 집 안에 방을 만듭니다. 구성 ----> 합성 | 구성. 집계 -------> 그룹 | 요소

---

용어를 설정합시다. 집계는 UML 표준의 메타 용어이며 단순히 shared 라는 이름의 구성 및 공유 집계를 의미 합니다. 종종 "집계"로 잘못 명명됩니다. 구성도 집계이기 때문에 BAD입니다. 내가 알기로는 "공유"를 의미합니다.

UML 표준에서 추가 :

복합-속성이 복합적으로 집계됨을 나타냅니다. 즉, 복합 객체가 구성된 객체 (부품)의 존재 및 저장을 담당합니다.

따라서 카테 드라는 대학 (IMHO) 외부에 존재하지 않기 때문에 대학과 카테 드라 연결은 구성입니다.

공유 집계의 정확한 의미는 애플리케이션 영역과 모델러에 따라 다릅니다.

즉, 자신이나 다른 사람의 일부 원칙 만 따르는 경우 다른 모든 연결을 공유 집계로 그릴 수 있습니다. 또한 여기를보십시오 .

---

신장, 간, 뇌와 같은 인체 부위를 고려하십시오. 여기서 구성과 집계의 개념을 매핑하려고하면 다음과 같습니다.

신장과 간과 같은 신체 부위 이식이 도래하기 전에는이 두 신체 부위가 인체와 구성되어 있었기 때문에 인체와 분리되어 존재할 수 없었습니다.

그러나 신체 부위 이식의 도래 후에는 다른 인체에 이식 할 수 있기 때문에,이 부분은 이제 인체와 분리되어 존재하는 것이 가능 해져 인체와 응집되어 있습니다.

참고 URL : https://stackoverflow.com/questions/734891/aggregation-versus-composition