객체 간의 관계(의존성,연관관계....)

 

 

객체 간의 관계

상속 및 구현 외에도 객체들 사이에는 다른 유형의 관계들이 있다.

 

*STL(Stabdard Template Library,표준 템플릿 라이브러리): 개체들을 보관하기 위한 다양한 자료구조와 이들 자료구조에 보관된 개체들을 반복적으로 순회할 수 있게 해 주는 반복자, 사용자에서 정의한 코드를 입력 인자로 전달받아 처리할 수 있게 추상화한 함수 개체, 다양한 문제 해결 방법이 구현된 함수들로 구성된 알고리즘 등으로 구성되어 있다.

 

*컴포넌트: 소프트웨어에서도 단자의 규격 같은 장치가 필요하다. 객체지향 언어에서는 이러한 장치를 인터페이스(Interface)로 제공해준다. 인터페이스는 사용자에게 해당 소프트웨어를 사용하기 위한 메소드(=장치)를 공개하고, 규격화된 메소드 환경에서 소프트웨어를 개발할 수 있는 환경을 제공해준다. 

 

결론적으로 컴포넌트는 각각 독립된 모듈을 뜻하며, 이는 흔히아는 JAVA같은 oop언어등의 class 개념과는 다르다. 하나의 컴포넌트는 하나의 클래스로만 작성될 수 도 있지만, 여러개의 클래스로도 작성될 수 있기 때문이다.

 

*컨테이너: STL에서 컨테이너는 같은 타입의 여러 객체를 저장하는 일종의 집합이라고 할 수있다. 컨테이너는 클래스 템플릿으로, 컨테이너 변수를 선언할 때 컨테이너에 포함할 요소의 타입을 명시할 수 있다. 또한 컨테이너에는 복사 생성과 대입 할 수 있는 타입의 객체만을 저장할 수 있다. 컨테이너 요소의 추가 및 제거를 포함한 다양한 작업을 도와주는 여러 멤버 함수를 포함하고 있다.

 

의존성

의존성 UML.교수는 강의 자료에 의존한다.

의존성은 클래스 간의 가장 기본적이고 약한 유형의 관계이다. 한 클래스의 정의를 일부 변경했을때 다른 클래스가 변경되는 경우 두 클래스 사이에 의존성이 있다고 할 수 있다. 의존성은 일반적인 코드에서 구상 클래스 이름들을 사용할 때 만들어 진다. (ex 메서드 시그니처 유형들을 지정할 때, 생성자 호출들을 통해 객체들을 인스턴스화할 때 등)

 

*메서드 시그니처(Method signature) : Java에서 메서드를 정의할 때 메서드 이름과 매개변수 리스트의 조합을 말한다. 메서드 이름과 매개변수 리스트가 중요한 이유는 오버로딩 때문이다. Java 컴파일러는 메서드 이름과 매개변수 리스트를 통해 메서드 간의 차이를 식별한다.

 

코드를 구상 클래스가 아닌 인터페이스나 추상 클래스에 의존하게 만들면 의존성을 약화할 수 있다.

 

일반적으로 UML 다이러그램은 모든 의존관계를 표시하지 않는다.  왜냐하면 실제 코드에는 너무나도 많은 의존관계들이 있기 때문이다. 따라서 의존 관계로 다이어그램을 복잡하게 만드는 대신, 나타내고자 하는 아이디어에 중요한 관계들만 매우 선별적으로 표시해야 한다.

연관관계

연관관계 UML. 교수는 학생들과 서로 대화한다.

연관은 한 객체가 다른 객체를 사용하거나 이 두 객체가 상호 작용하는 관계이다. UML 다이어그램에서 연관관계는 한 객체에서 그 객체가 사용하는 객체로 향하는 간단한 화살표로 표시된다.

 

참고로 객체 서로 양방향 연관 관계가 있을 수 도 있으며, 그런 경우 화살표의 양 끝에 화살표가 있다. 연관은 특수한 종류의 의존관계로 간주할 수 있으며, 이때 객체는 언제나 상호작용하는 객테에 접근할 수 있다.

 

일반적으로 다른 객체가 포함된 필드를 나타낼 때는 연관관계를 사용한다. 이 필드(속성)은 두 객체간의 링트 역할을 한다. 하지만 늘 필드일필요는 없고 연관관계의 일부는 객체를 반환하는 메서드로 나타날 수 도 있다.  그렇지 않다면, 인터페이스에는 필드가 없기 때문에 인터페이스에서는 객체간의 연관관계를 나타낼 수 없을 것이다.

 

Professor 클래스

import { Course } from "./course";
import { Student } from "./sutudent";
export class Professor {
  student: Student;

  public teach(course: Course) {
    this.student.remember(course.getKnowledge());
  }
}

Course 클래스

import { Subject } from "./subject";

export class Course {
  subject: Subject;

  public getKnowledge() {
    return "get knowledge";
  }
}

 

Professor클래스의 teach메서드를 살펴보자 이메서드는 course(수업과정)클래스를 인수로 받으며, 이 인수는 메서드의 본문에서 사용된다. 누군가가 getKnowledge메서드의 시그니쳐를 변경하면(ex:이름을 바꾼다든지 또는 필요한 매개변수를 추가한 다던지 등) 더이상 코드가 작동하지 않는다.

 

바로 이것이 Professor클래스가 Course클래스에 의존한다고 말할 수 있는 이유이다.

 

이제 student 필드를 살펴보고 해당 필드가 teach메서드에서 어떻게 사용되는지도 살펴보자 Student 클래스는 Professor 클래스에 의존하는 dependency라고 확실히 말할 수 있다.

 

왜냐면 remember메서드의 시그니처가 변경되면 Professor의 코드가 깨지기 때문이다. 그러나 Professor의 모든 메서드는 student필드(멤버변수,멤버메서드 모두 포함)에 접근할 수 있으므로, Student 클래스는 Professor에 의존하는 dependency일 뿐만이 아니라 Professor과 연관 관계가 있기도 하다. 

 

집합관계

집합 관계의 UML 학과는 교수들을 포함한다.

 

여러 객체 간의 '일-대-다' , '다-대-다' 또는 '전체-부분' 관계들을 나타내는 특수 한 유형의 연관 관계이다. 

 

일반적으로 집합 관계에서 객체는 다른 객체들의 집합을 가지며, 컨테이너 또는 컬렉션 역활을 한다. 컴포넌트는 컨테이너 없이 존재할 수 있으면, 동시에 여러 컨테이너에 연결될 수 있다.

 

💡UML
UML에서 집합 관계는 컨테이너 끝에서 빈 다이아몬드가 달려있고 컴포넌트를 가리키는 끝부분에는 화살표가 달린 선으로 표시된다.

UML은 클래스들 간의 관계를 나타낸다. 이것은 다이어그램에서 각 사물이 하나의 '블록'만으로 표시되더라도 대학 객체가 여러 학과로 구성될 수 있음을 의미한다. 

UML 표기법에서는 관계의 양쪽에 수량을 표시할 수도 있지만 이 수량이 맥락상 명확하면 생략해도 된다.

 

합성관계

합성 관계 UML.대학은 많은 학과들을 포함한다.

합성 관계는 특정 유형의 집합 관계로, 여기서 객체(대학)는 다른 객체(학과)의 하나 또는 그 이상의 인스턴스로 구성된다. 

 

합성관계와 다른 관계들의 차이점은 컴포넌트가 컨테이너의 일부로만 존재할 수 있다는 것이다.

 

UML에서 합성 관계는 집합 관계와 동일하게 표시되지만, 화살표에 속이 채워진 다이아몬드가 추가된다.

 

많은 사람들이 '합성'이라는 용어를 합성과 집합 관계 모두를 뜻하는 상황에서 상용하곤 한다. 그 악명 높은 예시가 '상속 보다 합성을 선택하십시오'라는 유명한 원칙이다.

 

정리

'집합관계와 합성 관계의 차이점은 무엇입니까?' 또는 '상속 관계는 의존 관계의 일종입니까?'

 

 

• 의존 관계 : 클래스 A는 클래스 B가 변경될 때 영향을 받을 수 있다.
• 연관 관계 : 객체 A가 객체 B에 대해 알고 있다. 클래스 A는 B에 의존한다.
• 집합관계 : 객체 A가 객체 B에 대해 알고 있으며 B로 구성된다. 클래스 A는 B에 의존한다.
• 합성관계 : 객체 A각 객체 B에 대해 알고, B로 구성되며 B의 수명 주기를 관리한다. 클래스 A는 B에 의존한다.
• 구현관계 :  클래스 A가 인터페이스 B에 선언된 메서드를 정의한다. 객체 A는 B처럼 처리될 수 있습니다. 클래스 A는 B에 의존합니다.
• 상속 관계 : 클래스 A가 클래스 B의 인터페이스 및 구현 관계를 상속하지만 이를 확장할 수 있다. 객체 A는 B처럼 처리 될 수 있습니다. A는 B에 의존합니다.