🐢 chap7. 합성과 집합

⭐ 7.1 클래스 간의 관계

• 객체 모델은 관련된 객체에 대한 집합입니다.
• 관계의 수는 많더라도 두 객체 간 관계의 유형은 몇 가지 정도가 존재합니다. 일반적으로 객체 (또는 그에 해당하는 클래스)
• 두 객체 사이에 존재하는 관계의 유형 type과 그에 해당하는 클래스 : to-have와 to-be 두 가지 관계
• 합성 집합
  • to-have 관계 중 첫 번째인 합성 : 두 클래스 사이의 실제 합성 관계를 나타내는 예제가 제공됩니다. 이 예제로 합성 시 일반적으로 갖게 되는 메모리 구조를 살펴봅니다.
  • to-have 관계 중 두 번째인 집합aggregation: 집합은 합성과 비슷합니다. 둘 다 to-have 관계를 다루기 때문입니다.

⭐ 7.2 객체 대 클래스

• 객체 = 인스턴스다. → 결과물 (차를 만드는 재료)
  • 객체는 모든 인스턴스를 포괄하는 넓은 의미를 가지고, 인스턴스는 해당 객체가 어떤 클래스로 만들어 젔냐
• 클래스 → 찍어내는 기계 (차를 만들어 내는 기계 틀)
  • 객체를 정의한 설계도 또는 틀
• 구조체 : 명시적 캡슐화
• 구조체가 아닌 문법 : 암묵적 캡슐화

☑️ 객체 대 클래스

• 각 객체는 같은 클래스에서 인스턴스화 되어 서로 다른 객체가 존재하는 동일한 속성을 가진다

• 사람(클래스)

  • → 남자 (인스턴스) : 유재석, 정형돈 (사람이라는 속성)
  • → 여자 (인스턴스) : 이은지, 이유정 (사람이라는 속성)
• Person이라는 클래스를 정의한다고 가정해봅시다. (객체 예제)

typedef struct
{
    char name[32];
    char surname[32];
    unsigned int age;

} Person_t;

• 클래스는 name, surname, age라는 속성을 갖습니다. (클래스 예제)

class MyClass
{
public:
	std::string name;
	std::string family;
	uint32_t age;

};

• 프로토타입의 언어와 그렇지 않은 언어는 문법은 다를지 몰라도 내부 구조는 같다.(c 로 구현한 코드와 비슷 할 것이다. 프로토 타입의 언어는 메모리관리적인 부분을 코드로 적성하지 않는다.)

• 프로토 타입 접근법은 클래스를 공유하는 방법 또는 객체기반를 공유하는 방법
• 클래스 기반의 접근법에서는 클래스라는 속성 없이는 객체를 생성할 수 없음

코드 안에서 정의한 name, family 가 고유특성을 가지는 현상이 아니다.
컴퓨터 메모리지 name, family의 특성이 아니다.
컴퓨터 메모리를 생성하고 소멸하는 방법
생성자(메모리): 함수를 생성 지정 또는 호출
소멸자(메모리): 리소스를 해제하는 역할을 합니다.
생성자 (construction) : 생성 단계를 수행하도록 지정된 함수

생성자

1. 함수 지정
2. 사용시 car_construct(&car, "Renault");
3. 필요시 할당해주고

// 함수를 지정해주고
void car_construct(car_t* car, const char* name)
{
  strcpy(car->name, name);
  car->speed = 0.0;
  car->fuel = 0.0;
}
// main에서 사용시 (사용시)
car_construct(&car, "Renault");

//286 페이지 할당하는법
list_t* list_malloc()
{
  return (list_t*)malloc(sizeof(list_t));
}

// main 할당
car_construct->make = malloc(strlen(make) + 1);
car_construct->model = malloc(strlen(model) + 1);

• 예제에서 함수 car_construct가 생성자 함수였습니다. 객체를 생성하는 과정에서는 해당 객체에 필요한 다른 객체나 버퍼, 배열, 스트림 등과 같은 리소스에 대해 훨씬 더 많은 메모리를 할당해야 할 수도 있습니다.
• 소멸자
  • 객체가 소멸한 뒤 할당된 메모리가 해제하면서 객체가 소유한 모든 리소스와 그에 해당하는 메모리가 먼저 비워져 소멸하는 현상

소멸자

void list_destroy(list_t* list)
{
  // Deallocates the allocated memory
  free(list->items);
}
 car_destruct(&car);

• 앞에서와 마찬가지로 이전 장의 예제에서 함수 list_destory와 car_destruct는 소멸자에 해당합니다.
• 객체가 소멸한 뒤 할당된 메모리가 해제됩니다.

• 하지만 그 전에 객체가 소유한 모든 리소스와 그에 해당하는 메모리가 먼저 비워져야 합니다.

  • 클래스는 객체를 만들기 위한 지도로 사용되는 청사진입니다.
  • 같은 클래스에서 여러 객체를 만들 수 있습니다. ( 차 : 소나타, 그랜저)
  • 클래스는 해당 클래스를 기반으로 만들 모든 객체에 존재해야 할 속성이 어느 것인지 결정합니다.
• 클래스는 속성이 가질 값에 관해서는 아무것도 설명하지 않습니다.
• 클래스 자체로는 메모리를 사용하지 않습니다(C나 C++가 아닌 몇몇 언어는 제외).
• 클래스는 소스 파일 단계 및 컴파일 시에만 존재합니다.

• 객체는 런타임 시에 존재하고 메모리를 사용합니다.

• 객체를 만들 때는 먼저 메모리를 할당해야 합니다.
  • 덧붙여 메모리 해제는 객체에 대한 마지막 작업입니다.
• 객체를 만들 때, 객체는 메모리 할당 직후에 생성해야 합니다.
  • 또한 메모리 해제 직전에 객체가 소멸해야합니다

객체는 스트림, 버퍼, 배열 등과 같은 리소스를 소유합니다.
이들은 객체가 소멸하기 전에 반드시 해제되어야 합니다

⭐ 7.3 합성

✅ 합성 (composition)

• 한 객체가 다른 객체를 포함하거나 소유할 때, 즉 한 객체가 다른 객체들로 구성될 때
• 이들 객체 사이에 합성 관계가 있다고 할 때 사용된다.
• ex) 자동차는 엔진을 가진다.
  • → 자동차는 엔진 객체를 포함하는 객체 즉 합성관계

✅ 합성관계가 가지는 조건

• 컨테이너에 포함된 객체의 수명은 컨테이너 객체의 수명에 바인딩됩니다.
• 컨테이너 객체가 존재하는 한, 컨테이너에 포함된 객체도 반드시 존재해야 합니다.
• 컨테이너 객체가 소멸할 때는 포함된 객체가 먼저 소멸해야 합니다.
  • → 포함된 객체가 컨테이너에 비해 더 내부적이고 비공개적
• 포함된 객체의 일부는 컨테이너 클래스의 공용 인터페이스(혹은 행위 함수)를 통해 여전히 접근할 수도 있습니다. 하지만 포함된 객체의 수명은 컨테이너 객체에 의해 내부적으로 반드시 관리되어야 합니다.
• 코드가 컨테이너에 포함된 객체를 먼저 소멸시키지 않고도 컨테이너 객체를 소멸시킬 수 있다면, 이는 합성 관계를 위반하는 것이며 더 이상 이 관계는 합성이 아닙니다.
• 코드 박스 7-3 [예제 7-1] Car 클래스의 공용 인터페이스(ExtremeC_examples_chapter7_1_car.h)

#ifndef EXTREME_C_EXAMPLES_CHAPTER_7_1_CAR_H
#define EXTREME_C_EXAMPLES_CHAPTER_7_1_CAR_H
struct car_t;
// 메모리 할당자
struct car_t* car_new();
// 생성자
void car_ctor(struct car_t*);
// 소멸자
void car_dtor(struct car_t*);
// 행위 함수
void car_start(struct car_t*);
void car_stop(struct car_t*);
double car_get_engine_temperature(struct car_t*);
#endif

속성 구조체 car_t만을 선언. 이 구조체의 필드는 정의하지 않았으며, 이는

• 전방 선언 forward declaration이라고 합니다. 전방 선언은 식별자 (예: 클래스, 함수 또는 변수)의 전체 정의를 제공하기 전에 그 존재를 선언하는 문

코드 박스 7-3 [예제 7-1] Engine 클래스의 공용 인터페이스(ExtremeC_examples_chapter7_1_car.h)

#ifndef EXTREME_C_EXAMPLES_CHAPTER_7_1_ENGINE_H
#define EXTREME_C_EXAMPLES_CHAPTER_7_1_ENGINE_H
struct engine_t;
// 메모리 할당자
struct engine_t* engine_new();
// 생성자
void engine_ctor(struct engine_t*);
// 소멸자
void engine_dtor(struct engine_t);
// 행위 함수
void engine_turn_on(struct engine_t*);
void engine_turn_off(struct engine_t*);
double engine_get_temperature(struct engine_t*);

#endif

• 코드박스 7-5 [예제 7-1] Car 클래스에 대한 정의(ExtremeC_examples_chapter7_1.car.c)

#include <stdlib.h>
// Car Engine에 대한 공용 인터페이스로만 작동할 수 있습니다.
#include "ExtremeC_examples_chapter7_1_engine.h"

typedef struct {
// 이 속성으로 인해 합성이 발생
struct engine_t* engine;
} car_t;

car_t* car_new() {
return (car_t*)malloc(sizeof(car_t));
}

void car_ctor(car_te car) {
// 엔진 객체에 대해 메모리 할당하기
car->engine = engine_new();
// 엔진 객체 생성하기
engine_ctor(car->engine);
}

void car_dtor(car_t* car) {
// 엔진 객체 소멸시키기
engine_dtor(car->engine);

// 엔진 객체에 할당된 메모리 비우기
free(car->engine);
}

void car_start(car_t* car) {
engine_turn_on(car->engine);
}

void car_stop(car_t* car) {
engine_turn_off (car->engine);
}

double car_get_engine_temperature(car_t* car) {
return engine_get_temperature(car->engine);
}

• 앞의 코드 박스는 자동차가 엔진을 포함하는 방식

  • car_t 속성 구조체에 새로운 속성이 있는데 이는 struct engine_t형입니다.

    → *이 속성 때문에 합성이 발생*
    

  • struct engine_t

    struct engine_t는 소스 파일 내에서 여전히 불완전한 형식이지만, 런타임 시에 완전한 형식인 engine_t 의 객체를 가리킬 수 있습니다. 이 속성은 Car 클래스의 생성자에서 생성 할 객체를 가리키며, Car 클래스의 소멸자 내부에서 해제됩니다. 생성 및 해제 부분에는 둘 다 car 객체가 존재하며, 이는 자동차의 수명에 엔진의 수명이 포함된다는 뜻입니다.

  • engine 포인터는 비공개이고, 구현에서는 어느 포인터도 유출되지 않습니다.

  • → 합성 관계를 구현할 때 포인터가 유출되면 안 됩니다.

    만약 유출된다 면, 포함된 객체의 상태를 외부 코드가 변경할 수 있게 됩니다. 캡슐화와 마찬가지로 포인터가 어떤 객체의 비공개 부분을 직접 접근하도록 할 경우에는 유출되면 안 됩니다. 비공개 부분은 언제나 행위 함수로 간접적으로 접근해야 합니다.

  • 코드 박스에서 car_get_engine_temperature 함수는 엔진의 temperature 속성에 대한 접근을 허용
  • 또한 이 함수는 엔진의 공용 인터페이스를 사용합니다. 잘 살펴보면,
  • 자동차에 대한 비공개 구현은 엔진의 공용 인터페이스를 사용
    • → 자동차 그 자체로는 엔진에 대한 구현의 세부 사항에 대해서는 모른다는 의미 즉
  • 같은 자료형이 아닌 두 객체는 상대의 구현에 대한 세부사항을 몰라야 한다!

• 이제 Engine 클래스에 대한 구현을 살펴봅시다. 코드박스 7-6[ 예제7-1] Engine 클래스에 대한 정의(ExtremeC_examples_chapter7_1_engine.c)

#include <stdlib.h>
typedef enum {
ON, // 0
OFF // 1
} state_t;

typedef struct {
state_t state;
double temperature;
} engine_t;

// 메모리 할당자
engine_t* engine_new() {
return (engine_t*)malloc(sizeof(engine_t));
}

// 생성자
void engine_ctor (engine_t* engine) {
engine->state = OFF;
engine->temperature = 15;
}

// 소멸자
void engine_dtor(engine_t* engine) {
// 할 일 없음
}

// 행위 함수
void engine_turn_on (engine_t* engine) {
if (engine->state == ON) {
	return;
}
engine->state = ON;
engine->temperature = 75;
}

void engine_turn_off (engine_t* engine) {
if (engine->state == OFF) {
return;
}
	engine->state = OFF;
	engine->temperature = 15;
}

double engine_get_temperature(engine_t* engine) {
	return engine->temperature;
}

• 위 코드는 암묵적 캡슐화 접근법!

• 그렇다면 engine 객체는 car에 대해 알고 있을까? 회사가 엔진을 만들때 어느 엔진이 차에 잘 맞을지 확실치 않은 것처럼 외부 객체는 모른다

• 다음 [코드 박스 7-7]은 car 객체를 만들고 자동차 엔진과 관련된 정보를 추출하기 위해 공용 API를 호출하는 시나리오입니다.
• 코드박스 7-7 [예제 7-1]의 main 함수(ExtremeC_examples_chapter7_1_main.c)

#include <stdio.h>
#include <stdlib.h>
#include "ExtremeC_examples_chapter7_1_car.h"

int main(int argc, char** argv) {
// 자동차 객체에 대해 메모리 할당
struct car_t *car = car_new();

// 자동차 객체를 생성
car_ctor(car);
printf("자동차 객체가 시작되기 전의 엔진 온도: %f\n", car_get_engine_temperature(car));
car_start(car);
printf("자동차 객체가 시작된 뒤의 엔진 온도: %f\n", car_get_engine_temperature(car));
car_stop(car);
printf("자동차가 멈춘 뒤의 엔진 온도: %f\n", car_get_engine_temperature(car));

// 자동차 객체 소멸
car_dtor(car);

// 자동차 객체에 대해 할당된 메모리 해제
free(car);
return 0;
}

• 셸 박스 7-1 [예제 7-1]의 컴파일, 링크, 실행

$ gcc -c ExtremeC_examples_chapter7_1_engine.c -o engine.o
$ gcc -c ExtremeC_examples_chapter7_1_car.c -o car.o
$ gcc -c ExtremeC_examples_chapter7_1_main.c -o main.o
$ gcc engine.o car.o main.o -o ex7_1.out
$ ./ex7_1.out
Engine temperature before starting the car: 15.000000
Engine temperature after starting the car: 75.000000
Engine temperature after stopping the car: 15.000000

1 .앞의 예제를 빌드하려면 우선 이전의 소스 파일 3개를 컴파일

2 .그다음 함께 링크해 최종 실행 가능한 목적 파일을 만들기

• 메인 소스 파일(main 함수를 포함하는 소스 파일)은 car의 공용 인터페이스에만 의존하니 주의하세요. 그러므로 링크 시 메인 소스 파일 은 car 객체의 비공개 구현만 필요합니다.
• 하지만 car 객체에 대한 비공개 구현은 engine 인터페이스의 공용 인터페이스에 의존합니다. 그러므로 링크 단계에서 engine 객체에 대한 비 공개 구현을 제공해야 합니다.
• 따라서 최종 실행 파일을 만들려면 객체 파일 3개를 모두 링크 해야합니다.

⭐ 7.4 집합

✅ 집합(aggregation)

• 집합은 다른 객체를 포함하는 컨테이너 객체를 동반
• 집합 관계에서는 컨테이너에 포함 된 객체의 수명이 컨테이너 객체의 수명에 독립적이라는 점이 합성과의 주된 차이점입니다.
• 집합에서 컨테이너에 포함된 객체는 컨테이너 객체가 생성되기 이전에도 생성될 수 있습니다. 이는 합성과 정반대입니다. 합성의 경우 컨테이너에 포함된 객체가 컨테이너 객체의 수명보다 더 짧거나 같아야 합니다.

다음 [예제 7-2]는 집합 관계

• player 객체는 잠시 컨테이너 객체가 됩니다.
• gun 객체는 플레이어 객체가 총을 들고 있는 동안에는 컨테이너에 포함된 객체가 됩니다. gun 객체의 수명은 player 객체의 수명에 독립적입니다.

다음 [코드 박스 7-8]은 Gun 클래스의 헤더 파일을 나타냅니다. 코드 박스 7-8 [예제 7-2] Gun 클래스의 공용 인터페이스(ExtremeC_examples_chapter7_2.gun.h)

#ifndef EXTREME_C_EXAMPLES_CHAPTER_7_2_GUN_H
#define EXTREME_C_EXAMPLES_CHAPTER_7_2_GUN_H

typedef int bool_t; // int  == bool_t로 쓰겠다
// 전방 선언
struct gun_t;

// 메모리 할당자
struct gun_t* gun_new();

// 생성자
void gun_ctor(struct gun_t*, int);

// 소멸자
void gun_dtor(struct gun_t*);

// 행위 함수
bool_t gun_has_bullets(struct gun_t*);
void gun_trigger(struct gun_t*);
void gun_refill(struct gun_t*);
#endif

다음 코드 박스7-이는 Player 클래스의 헤더 파일입니다. 코드 박스 7-9[예제 7-2] Player 클래스의 공용 인터페이스(ExtremeC_examples_chapter7_2_player.h)

#ifndef EXTREME_C_EXAMPLES_CHAPTER_7_2_PLAYER_H
#define EXTREME_C_EXAMPLES_CHAPTER_7_2_PLAYER_H

// 전방 선언
struct player_t;
struct gun_t;

// 메모리 할당자
struct player_t* player_new();

// 생성자
void player_ctor(struct player_t*, const char*);

// 소멸자
void player_dtor(struct player_t*);

// 행위 함수
void player_pickup_gun(struct player_t*, struct gun_t*);
void player_shoot(struct player_t*);
void player_drop_gun(struct player_t*);

#endif

• 이 코드는 모든 플레이어 객체의 공용 인터페이스 즉, Player 클래스의 공용 인터페이스를 정의
• 다시 강조하지만 gun_t 및 player_t 구조체에 대해 전방 선언해야 합니다.

→ gun_t형을 선언 해야 Player 클래스에서 행위 함수가 gun_t형에 대한 인수를 갖기 때문

Player 클래스에 대한 구현은 다음과 같습니다.

코드 박스 7-10 [예제 72] Player 클래스에 대한 정의(ExtremeC_examples_chapter7_2_player.c)

# 코드 박스 7-10 [예제 72] Player 클래스에 대한 정의(ExtremeC_examples_chapter7_2_player.c)
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include "ExtremeC_examples_chapter7_2_gun.h"

// 속성 구조체
typedef struct {
char* name;
struct gun_t* gun;
} player_t;

// 메모리 할당자
player_te player_new() {
	return (player_t*)malloc(sizeof(player_t));
}

// 생성자
void player_ctor(player_t* player, const char* name) {
	player->name =
		(char*)malloc((strlen(name) + 1) * sizeof(char));
		strcpy(player->name, name);
		// 중요한 부분입니다. 생성자에서 집합 포인터가 설정되지 않는 경우,
		// 집합 포인터를 NULL로 두어야 합니다.
player->gun = NULL;
}

// 소멸자
void player_dtor(player_t* player) {
	free(player->name);
}

// 행위 함수
void player_pickup_gun(player_t* player, struct gun_t* gun) {
//다음 행 이후, 합성 관계가 시작됩니다.
	player->gun = gun;
}

void player_shoot(player_t* player) {
// 플레이어가 춤을 들었는지 확인해야 합니다.
// 총을 들지 않았다면, 발사가 무의미합니다.
if (player->gun) {
gun_trigger(player->gun);
} else {
	printf("플레이어는 쏘고 싶지만 총이 없습니다!");
	exit(1);
	}
}

void player_drop_gun(player_t* player) {
// 다음 행 이후 두 객체 간 합성 관계가 종료됩니다.
// 총 객체는 해제하면 안 됩니다.
// 플레이어 객체는 합성 때처럼 총 객체의 소유자가 아니기 때문입니다.
player->gun = NULL;
}

• player_t 구조체 내부에서 포인터 속성인 gun을 선언하는데 이 속성은 곧 gun 객체를 가리킴 → 생성자에서는 이 속성을 NULL로 두어야 하는데, 합성과는 달리 이 속성이 생성자에서 설정

        **되지 않기 때문**
  

• 의무적 집합mandatory aggregation
  • 만약 집합 포인터가 생성 시 설정되어야 한다면, 대상 객체의 주소를 생성자의 인수로 전달해야 합니다. 이러한 상황은 의무적 집합mandatory aggregation이라고 합니다.

• 선택적 집합optional aggregation

  • 만약 집합 포인터가 생성자에서 NULL로 남아 있을 수 있다면 선택적 집합optional aggregation이며 앞의 코드가 이에 해당합니다. 생성자에서 선택적 집합 포인터를 NULL로 두는 것이 중요합니다.
• player_pickup_gun 함수에서는 집합 관계가 시작되며 player_drop_gun 함수에서 이 관계가 종료
• 집합 관계가 종료된 뒤 gun 포인터를 NULL로 두어야 한다는 점을 명심
• 합성과 달리 컨테이너 객체는 컨테이너에 포함된 객체의 소유자가 아닙니다. 그러므로 포함된 객 체에 대한 통제 권한이 없습니다. 따라서 player의 구현 코드 내에서 어디에서도 gun 객체를 해제하면 안 됩니다.
• 선택적 집합 관계에서는 프로그램의 어느 지점에서 포함된 객체를 설정하지 않았을 수 있습니 다. 그러므로 집합 포인터를 사용할 때는 조심해야 합니다. 포인터에 대한 어떤 접근도 설정되지 않았고, 널인 포인터는 세그멘테이션 오류를 일으킬 수 있기 때문입니다. 기본적으로 이러한 이유로 player_shoot 함수에서 gun 포인터가 유효한지 체크해야 합니다.
• 집합 포인터가 NULL이라면, player 객체를 사용하는 코드는 이 객체를 잘못 사용한다는 의미가 됩니다. 이때는 프로세스의 exit 코드로 1을 반환해 실행을 중단합니다.

코드박스 7-11 [예제 7-2] Gun 클래스에 대한 정의(ExtremeC_examples_chapter7_2_gun.c)

#include <stdlib.h>

typedef int bool_t;

// 속성 구조체
typedef struct {
int bullets;
} gun_t;

// 메모리 할당자
gun_t* gun_new() {
	return (gun_t*)malloc(sizeof(gun_t));
}

// 생성자
void gun_ctor(gun_t* gun, int initial_bullets) {
	gun->bullets = 0;
	if (initial_bullets > 0) {
		gun->bullets = initial_bullets;
	}
}

// 소멸자
void gun_dtor(gun_t* gun) {
// 할 일 없음
}

// 행위 함수
bool_t gun_has_bullets(gun_t* gun) {
	return (gun-> bullets > 0);
}

void gun_trigger(gun_t* gun){
	gun->bullets--;
}

void gun_refill(gun_t* gun) {
	gun->bullets = 7;
}

마지막으로 다음 코드 박스 7-12]는 플레이어 객체와 총 객체를 생성하는 짧은 시나리오

1. 플레이어는 총을 집어 들고 탄약이 남지 않을 때까지 총을 발사합니다.

2. 그다음 플레이어는 총을 재장전해 같은 행위를 합니다.
3. 마지막에는 총을 내려놓습니다.

코드 박스 7-12 [예제 7-2]의 main 함수(ExtremeC_examples_chapter7_2_main.c)

#include <stdio.h>
#include <stdlib.h>
#include "ExtremeC_examples_chapter7_2_player.h"
#include "ExtremeC_examples_chapter7_2_gun.h"

int main(int argc, char** argv) {
// 총(gun) 객체를 만들고 생성하기
struct gun_t* gun = gun_new();
gun_ctor(gun, 3);

// 플레이어(player) 객체를 만들고 생성하기
struct player_t* player = player_new();
player_ctor(player, "Billy");

// 집합 관계가 시작됩니다.
player_pickup_gun(player, gun);

// 총알이 남지 않을 때까지 씁니다.
while (gun_has_bullets(gun)) {
player_shoot(player);
}

// 총을 재장전(refill)합니다.
gun_refill(gun);
// 총알이 남지 않을 때까지 씁니다.
while (gun_has_bullets(gun)) {
	player_shoot(player);
}

// 합성 관계를 종료합니다.
player_drop_gun(player);

// 총 객체를 소멸 및 해제합니다.
gun_dtor(gun);
free(gun);

// 플레이어 객체를 소멸 및 해제합니다.

player_dtor(player);
free(player);

return 0;
}

// 합성 관계를 종료합니다.
//player_drop_gun(player);

// 총 객체를 소멸 및 해제합니다.
gun_dtor(gun);
free(gun);

// 플레이어 객체를 소멸 및 해제합니다.
player_shoot(player);
player_dtor(player);
free(player);

gun과 player 객체는 서로에 대해 독립적입니다.

집합에서 중요한 점은 포함된 객체의 수명을 컨테이너 객체가 변경하지 못한다는 점입니다.

void gun_dtor(gun_t* gun) {
// 할 일 없음
}
.
.
.

gun_dtor(gun);
free(gun);
-> 이 두개를 합치지 않은 이유는..?

다음 [셸 박스7-2]는 실행 파일을 빌드하고 실행하는 방법을 나타냅니다. 보다시피 [코드 박스 7-12]의 main 함수는 아무것도 출력하지 않습니다.

셸 박스 7-2 [예제 7-2]의 컴파일, 링크, 실행

$ gcc -c ExtremeC_examples_chapter7_2_gun.c -o gun.o
$ gcc -c ExtremeC_examples_chapter7_2_player.c -o player.o
$ gcc -c ExtremeC_examples_chapter7_2_main.c -o main.o
$ gcc gun.o player.o main.o -o ex7_2.out
$ ./ex7_2.out
$

• 실제 프로젝트에서 생성된 객체 모델에서, 집합 관계는 합성 관계의 수보다 일반적으로 더 많다.
• 집합 관계는 외부 코드에서 더 많이 볼 수 있다

→ 집합 관계를 만들려면 최소한 컨테이너 객체의 공용 인터페이스에서 지정된 일부 행위 함수가 포 함된 객체를 설정 및 재설정해야 하기 때문

• 앞의 예제에서처럼 gun과 player 객체는 처음에는 분리 → 잠시 연관 → 곧 다시 분리됩니다.

이는 집합 관계가 영구적인 관계인 합성 관계와는 달리 일시적이라는 의미.

이는 합성이 객체 간 소유 possession (to-have) 관계의 더 강한 형태이며, 반면 집합은 더 약한 관계임을 나타냅니다.

• 만약 집합 관계가 두 객체 사이에서 일시적이라면, 객체에 해당하는 클래스 사이에서도 관계가 일시적일까요?
  • → 아닙니다. 집합 관계는 클래스에서는 영구적 입니다. 만약 나중에 서로 다른 자료형의 두 객체가 집합 관계를 기반으로 관계가 생길 조금의 여지가 있다면, 이 자료형은 영구적으로 집합 관계여야 합니다. 합성도 마찬가지입니다.

⭐ 7.5 마무리

• 클래스와 객체 간에 가능한 관계의 유형

• 클래스, 객체, 인스턴스, 참조 사이의 차이와 유사성

• 합성에서 컨테이너에 포함된 객체는 자신을 포함하는 컨테이너 객체에 전적으로 의존합니다.

• 집합에서는 컨테이너에 포함된 객체가 컨테이너 객체에 어떠한 의존성도 갖지 않습니다.

• 객체 사이에서 집합이 일시적일 수 있으나 객체의 자료형(또는 클래스) 사이에서는 영구불변한 것으로 정의됩니다.