오전 중으로 깃허브 리드미 작성과 팀 프로젝트 결과물을 제출했다.
12시까지였지만 제출이 열린 시간이 어제 오후부터 였으니까
마감 시간에 맞게 아슬아슬하게 제출했다.
발표에서 실시간으로 피드백이 이루어지는 걸 감안하면 사실 적절하게 제출한 것은 아니다.
피드백을 해주는 튜터님도 코드를 볼 시간은 있어야하니까.
다음부터는 더 빨리 제출하는게 좋을 것 같다.
생각보다 젤리 컨셉과 젤리에 물리 적용을 한 것이 반응이 좋았나보다. 왜지
남는 시간에 개인과제 때 받은 피드백을 한번 시도해봤다.
내가 현재 자주 사용하는 방법이다.
이렇게 메인이 되는 매니저를 싱글톤으로 만들고 필요한 클래스들을 받아와 사용하고 있다.
단점은 이렇게 사용하면 아래와 같은 일이 벌어진다.
보다시피 CharacterSelection, PlayerManager에 접근하기 위해 MainManager를 거쳐야한다.
불필요하게 MainManager에 접근하면서 비효율이 발생하는 것이다.
그리고 저렇게 접근하는게 메모리에 좋지도 않다. 호출 시마다 메모리에 쌓인다.
ex) MainManager가 한 번 쌓이고, PlayerManager가 한 번 쌓이고...
그래서 그랬는지 개인 과제에서 이런 피드백을 받았다.
그래서 지금처럼 시간이 날 때 구현해봤다.
using UnityEngine;
// 매니저 급의 스크립트들이 늘어나면 재사용하기 편해지므로
public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
private static T instance;
public static T Instance
{
get
{
if (instance == null)
{
// 필요하면 써야한다
Debug.Log("Find instance");
instance = FindObjectOfType<T>();
// 가급적 찾고나면 안으로
if (instance == null)
{
Debug.Log("Couldn't find instance. So make new one.");
GameObject go = new GameObject(typeof(T).Name);
instance = go.AddComponent<T>();
// 필요한 경우
DontDestroyOnLoad(go);
}
}
Debug.Log("Return instance");
return instance;
}
}
}
매니저 역할을 하는 클래스가 많아질수록 싱글톤처럼 사용할 일이 늘어난다.
그럴 때마다 각각의 클래스에 싱글톤 패턴을 구현 해놓기보다
위의 코드처럼 제네릭을 이용해서 구현해두고 상속받아 싱글톤을 사용하는 것이다.
어차피 똑같이 static으로 쓸거라면 접근 시 메모리가 덜 사용되는 방향으로 가는 것이 낫다.
아마 다음 프로젝트에서 매니저로 쓸 일이 많아지면 이 방법으로 갈 것 같다.
#내일배움캠프 #스파르타내일배움캠프 #스파르타내일배움캠프TIL