20231208_Generic, 오브젝트풀, SOLID원칙

오늘의 TIL은 스탠다드 특강에서 배웠던 내용들이다.

 

제네릭(List 등) : 마법상자

제네릭은 마법상자처럼 다양한 타입을 담을 수 있다
-> 코드의 재사용성과 유용성을 높일 수 있다.

List<T> 라고 작성해두면
이 T에 들어갈 수 있는 게 string, int 등이 모두 들어갈 수 있다.

함수를 만드는 경우에도  T 를 사용하면 여러 타입을 담는 것이 가능하다.

 

C#의 오버로딩(다형성의 좋은 예시)

함수가 하나의 기능만을 갖는 것이 아니라, 여러가지 기능을 갖고 있을 수 있다.
파라미터에 따라서 역할이 달라진다.

예
Random.Range(0, 5);
Random.Range(0f, 5f);
0, 5로 하면 int 값이 랜덤으로 나오지만, 0f, 5f로 하면 0.1, 0.24, 0.4의 float 값이 나온다.

 

오버라이딩

부모에서 작성한 함수를 자식에서 조금 다르게 수정해서 사용하는 것(재정의)
자식클래스의 객체를 부모클래스의 객체가 대체할 수 있게
리스코프 치환 원칙을 지켜서 사용해야한다.

 

오브젝트 풀

인재 풀 : 특정 기업이나 조직이 필요로 하는 인재들의 집합
현재 조직의 일원이 아니지만, 잠재적 채용 가능한 인원을 포함하는 개념.

오브젝트 풀은 미리 생성된 게임 오브젝트들을 관리하는 방식으로,
게임 실행 중에 오브젝트를 동적으로 생성하고 삭제하는 것보다 효율적입니다.

프리팹 -> 인스턴스화하고 꺼놓음 -> 오브젝트 풀 안으로 들어옴 -> 활성화 -> 실제 게임오브젝트로

 

 

오브젝트 풀 활용 이유

-  성능 향상 
오브젝트 생성 및 삭제는 비용(메모리 할당/해제 및 이로 인한 GC)이 많이 들기 때문에, 
미리 생성된 오브젝트를 재활용하여 성능을 향상시킵니다.
(GC : Garbage Collector, Garbage Collection)
-  메모리 관리
오브젝트 풀을 사용하면 게임 실행 중에 오브젝트를 반복적으로 생성하고 삭제하는 것보다 
메모리를 효율적으로 관리할 수 있습니다.

 

오브젝트 풀의 활용 사례

- 총알 
총알은 자주 생성되고 삭제되는 게임 오브젝트 중 하나입니다.
총알을 매번 생성하고 삭제하는 대신, 총알 오브젝트 풀을 사용하여 재활용할 수 있습니다.
-  적 캐릭터
적 캐릭터는 게임에서 자주 등장하는 오브젝트입니다.
많은 수의 적 캐릭터를 생성하고 제거하는 대신, 
적 캐릭터 오브젝트 풀을 사용하여 효율적으로 관리할 수 있습니다.

오브젝트 풀의 종류

-  미리 생성해두는 오브젝트 풀 (국룰)
Start에서 poolsize 만큼 해당 오브젝트를 생성한 뒤에 SetActive(false)로 꺼두고
상황에 따라 설정을 해둔다.
이후에 오브젝트를 요청하면 해당하는 오브젝트를 SetActive(true)로 만들어준다.
만약 오브젝트가 전부 사용했다면 null을 반환한다.
즉, 오브젝트 수가 한정되어 있는 것.

-> 미리 생성하기에 로딩 시간이 길어지는 단점이 있다.

-  제한이 있는 오브젝트 풀
 이펙트 같은 오브젝트. 사용이 끝난 오브젝트를 재사용할 수 있게 만든 오브젝트 풀

-  동적 오브젝트 풀 (국룰)
 미리 생성해두는 오브젝트 풀을 따라서
 어느 정도의 수의 오브젝트를 생성한 뒤에 SetActive(false)로 꺼두고
 이후에 오브젝트가 부족하면 오브젝트를 추가로 생성한다.

만약 오브젝트가 너무 많으면 문제가 생길 것으로 예상되면,
오브젝트의 한계 수를 지정하고 그 수를 넘기지 않게 생성하도록 지정한다.

 

오브젝트 풀을 사용해야되는 경우

- 오브젝트의 생성과 파괴가 잦다.
- 오브젝트를 많이 생성해야된다 (적어도 30)
- 오브젝트의 생성관리를 체계적으로 하고 싶다.
- 전부 같은 오브젝트인 경우 사용할 수 도 있지만, 같지 않은 오브젝트를 만들 수도 있다.

 

 

소프트웨어 설계와 객체지향 원칙

폭포수식 개발
 폭포수가 내려가듯이 개발의 방향이 한 방향으로 진행한다는 내용.
 요구사항 분석 -> 프로그램 설계 -> 구현/코딩 -> 테스트 -> 유지보수

게임은 폭포수식 개발이 정말 어렵다 (게임은 개발에서 변경이 잦다)
게임은 프로토식 개발, 에자일 개발이 많이 사용됨

Game의 core mechanics
-  AGON - 경쟁에서 이기는 즐거움
-  MIMICRY - 가족놀이 하듯이 역할을 맡고 그 역할을 하는 것
-  ILINX - 어지러움 같은 느낌을 받으면서 느끼는 즐거움
-  ALEA - 랜덤성에서 나오는 즐거움

게임에서 '설계'는 변경에 유연해져야된다는 점이 중요하다.

 

응집도와 결합도

높은 응집도(Cohesion)와 낮은 결합도(Coupling)는 좋은 소프트웨어의 특징입니다.
응집도는 모듈 내부에서 존재하는 구성 요소들 사이에 밀접한 정도를 나타내며,
결합도는 모듈과 모듈 사이의 관계에 관련 정도를 나타낸다.

 

 

소프트웨어 설계 원칙 - SOLID 원칙

SOLID 원칙은 객체 지향 프로그래밍 설계 원칙으로,
유지 보수 가능하고 확장 가능한 소프트웨어를 만들기 위한 원칙입니다.

 

S : 단일 책임 원칙 (Single Responsibility Principle)

의미 : 하나의 클래스는 하나의 책임만 가져야 한다.
각 클래스는 한 가지 목적을 위해 존재하고, 변경의 이유는 하나여야 한다.

-  예시 1
유니티 컴포넌트들의 사례
Transform : scale, rotation, position을 저장하고 이와 관련한 처리를 수행하는 클래스
RigidBody : 

-  예시 2
 Player 클래스를 만드는 경우에
 Audio, Input, Movement를 Class 안에 구현하면 이후에 관리가 어려워질 수 있다.

Player 클래스는 해당하는 Component를 들고 있고,
Audio, Input, Movement는 각각 함수로 따로 만들어서 구현하는 것이 관리하기 좋다.

-  중용의 미학
단일 책임 원칙을 수행하기 위해서는 클래스의 구조를 과도하게 정리하는 것은 위험합니다.
유니티에서는 세 가지 기준에 의해 단일책임원칙을 적용하라고 제안합니다.
기준 : 가독성 / 확장성 / 재사용성

 

O : 개방-폐쇄 원칙 (Open-Closed Principle)

의미 : 확장에는 열려있고, 수정에는 닫혀 있어야 합니다.
기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있도록 설계되어야 합니다.
추상 클래스 혹은 인터페이스를 활용하면 좋다.

 

 

 

나머지 SOLID 원칙은 다음 특강에서 다루기로 되어있다.

요즘 TIL을 작성하는 시간이 다른 이유들(팀 프로젝트, 개인 공부 등)으로

줄어든 것 같고, TIL의 질이 떨어진 것 같은 느낌이 들었다.

 

다음주부터는 TIL을 작성하는 시간을 할당하여 좀 더 양질의 TIL을 작성하면서

동시에 새로운 것을 배워나갈 수 있는 시간을 만들 예정이다.