[🐣질문] 코드 질문이 있는데, List를 래핑하고 있는데,

[익명(121.140)]

게임 내 캐릭터들의 리스트인데

캐릭터마다 고유 ID(int)가 있어서, 캐릭터들을 만들 때마다 idCount가 올라가면서 ID를 붙여줌

이제 리스트와 카운트를 같이 관리하고 싶어서

public class CharacterList 

{

 public int idCount;

private List<CharacterData> list; ~

이렇게 CharacterData의 리스트를 숨겼는데,

왜냐하면 리스트를 안 숨기면 내가 나중에 idCount 고치는걸 깜박하고 list의 내용만 수정할까봐 숨김

그런데 이러고 Push, Remove, Get 일일히 구현하려니 넘 귀찮고

기왕이면 참조로 작동하면 편할거 같은데, 왠지 일일히 구현하고 있다보니, 데이터를 값타입으로 관리해야할 것 같은 기분이 스물스물 들기 시작함..

혹시 내가 하고 있는 짓에 대해서 조언해줄 수 있을까?

이미 내가 필요한 기능이 있는지, 아니면 뻘짓하고 있는건지 등등...

[익명(14.42)]

list count, indexof

[익명(121.140)]

ㄴㄴ 캐릭터 아이디 주는거, 중간에 삭제되는 캐릭터가 있으면 리스트 카운트랑 idCount랑 다르게 되는

[익명(14.42)]

idCount가 필요없음. 캐릭터 30개면 list count해도 30개고, 중간에 3개빼면 27개그대로나옴. id도 필요없음. 인덱스가 곧 id임 중간에 빠져도 나중에 추가되도 알아서 인덱스가 땡겨지고 추가됌

[익명(14.42)]

그냥 근본적으로 자료구조에대한 이해나 설계에대한 미숙이 큰 문제로보임. 캐릭터가 id를 가지게하고싶다면. id는 캐릭터리스트 클래스가 아니라 캐릭터 클래스 스스로가 가지고있어야함. id의 할당은 캐릭터의 생성 시점에 전체 캐릭터의 갯수를가져와서 갱신하거나, lastindex의 캐릭터를가져와서 id++을 할당해주는식이어야 할것임

[익명(183.100)]

엥 스스로 가지고있을필요 없이 매니저에서 관리하고 그 매니저로부터 캐릭터가 id를 할당받게 하고 싶어서 저렇게 짜는걸텐데 왜 스스로 가지고 있어야한다그래 player가 얼마 없으면 그래도 되지만 많으면 많을수록 매니저 붙여서 player관리하는게 더 좋을거라고 보는데

[익명(14.42)]

매니저 클래스로 관리하는 의미에서도 마찬가지임. AddCharacter 함수를 구현하고, id는 last item의 id에서 ++하거나, count를 기준으로사용하면됌. idCount를 별도로 유지할시 문제가 많아짐 1. 쓸데없는 변수할당 2. add / remove / insert / 등 리스트에 관련된 기능을 사용할때마다 count변수에대한 관리를 별도로해줘야하는 복잡성증가 3. 심지어 public이라서 외부에서 어딘가에서 임의로 set 될수있는 문제가 열림 idCount라는 변수자체가 이상한변수임. id란 말 그대로 유니크 벨류를 의미함. id의 생성규칙에따라 이미 논리적으로 도출되는 값임 id가 누적일경우. last index의 id++가 next id이며,

[익명(183.100)]

그치 그래서 아래에서도 말했지만 list로 관리하는것보단 Dictionary가 더 상황에 맞을거고 idCount는 private으로 숨겨야겠지 내가 제공하는 함수에서만 set될수 있게 그리고 Dictionary로 관리하는 순간 인덱스도 없어지니까 필연적으로 idCount도 필요해질거고

[익명(14.42)]

캐릭터 리스트에 public idCount를 별도로 추가해서 얻어지는 장점은없고 단점만이 늘어남. 걍 이건 취향이나 스타일의 문제가아님. 구구절절 얽혀있는 부합하는 설계원칙에 관한 레퍼런스를 가져다가 주려면 할순있지만 삽질좀해보고 자기가 몸으로 익혀보면 혼자서도 깨우칠수있는 1학년 수준의 범주임. 캐릭터 테이블을 생각해보셈. id 이름 성별 직업 다 같은 라인에 들어가는 캐릭터의 속성임. id의 할당은 캐릭터의 생성시점에 결정되며 id는 유니크하고 생성 규칙이 일정하기때문에 외부리스트에서 별도의 idCount가 존재해선 안되는거임

[익명(183.100)]

왜 아까부터 나랑 다른소리를 하는거 같지.. public idCount는 왜 나오며 외부리스트에서 idCount가 존재해서는 안된다니 캐릭터들의 관리를 맡아서 할 매니저가 왜 외부리스트로 되는지 모르겠음 난 분명 idCount는 매니저가 관리해야하고 매니저가 제공하는 함수에서만 set해야하기때문에 private으로 해야한다고 말했고 그리고 뭐 설마 플레이어의 id를 동적으로 할당하는것말고 아예 데이터파일에서 플레이어의 id를 박아논다는건 아닐테고 매니저를 외부로 취급하면 도대체 Object들의 id관리는 누가함?...

[익명(14.42)]

심지어 이건 너가말한 딕셔너리를 이용한 방식에서도 동일함. count를별도변수에서 카운팅해서 기록해두는게아니라, 캐릭터 생성 함수에서 id할당시 딕셔너리에서 가장 큰 id값을 구해온 후 ++해서 할당하는식이 되어야함. 애초에 보통은 테이블을 따로 만들겠지만. 이래도되는데? 저래도되는데? 하지만 좋은 코드 좋은 설계인가는 다른문제임. 난 이런경우는 다르다가아니라 틀리다고생각하고 내가 잘나서가 아니라도 이미 수많은 나보다 잘난사람들이 제시한 가이드들의 기준을 토대로 얘기해도 같은것임. 어떤게 더 맞는방법인진 본인이 생각해서 판단하고 결정할문제임. 내가 틀릴수도있는거지.

[익명(183.100)]

그 Count도 매니저가 서버코드라고 본다면 가장 큰 id값에서 ++하는 방식은 좋지 않은게 그러면 언젠가 Unsigned int overflow가 일어날거고 그걸 예방하기 위해서라도 뭐 당장 생각나는 방법으로는 내부적으로 지워진 id를 담고있는 큐를 들고있다가 플레이어를 지우는 함수에서 id값을 큐에 넣은다음 추가할때 큐가 비어있지 않다면 그 id를 할당하도록 하는게 맞는 방법아님?

[익명(183.100)]

id테이블을 만든다는건 동적으로 캐릭터가 생성되지 않을것을 기준으로 했을때만 유효한 방안 아니야? 동적으로 어느 한 Object가 생성되면 그 Object의 id를 부여해줘야하는데

[익명(183.100)]

뭔가 지금 댓글을 보니까 너가 말한것들이 게임예시가 보편적이라기보단 싱글게임에다가 Object들이 처음 Init되고 나서 더 이상 생성되지 않을때를 기준으로 말한거 같네

[익명(14.42)]

오버플로우 얘기하는것도 별상관도없는 얘기임. 1씩증가하는 id만들어쓰는데 1. 별도 count를 만들어쓴다고 오버플로우가 안일어남? 2. 진심으로 저게말이된다고생각함? 매우 극단적인 예시를 가져가도 두케이스는 동일함. 생성시점, 삭제시점에서 id 찾아서 땡겨주고 증가시켜주는게 동일한 논리라면 결과가 똑같음. idCount가 없어서 생기는문제가뭐임?

[익명(183.100)]

안 일어나지 애초에 Dictionary를 이용하면 Dictionary자체로는 인덱스 접근도 불가능하고 인덱스 개념도 없기때문에 따로 count변수를 만들어서 id를 할당해야하고 이는 당연하게도 계속해서 Object들이 생성되면 될수록 count값이 늘어나는 구조일수 밖에 없음 예) 200번 Object 생성 -> 201번 Object 생성 -> 200번 Object 삭제 이러면 200번이 삭제되었다는것을 Dictionary에선 모름 그렇다고 200번 다음에 숫자를 할당하려고 하면 이미 201번 Object가 있음 이래서 아까 말한 Queue를 써서 이 200번을 들고있게 하고 다음 생성될때는 이 200번을 우선으로 할당하게 해주자 이거지 이러면 Unsigned int에 최대갯수인 2^32 - 1개의

[익명(183.100)]

Object가 동시에 생성되있지 않는한 Overflow문제를 피할수 있지

[익명(14.42)]

캐릭터 id 를 정의해보셈. 캐릭터가 가지는 고유한 유니크 키 이며, 생성시점에 생성규칙에 따라 결정된다. 생성규칙이 누적되는방식이면 last id++ 이고, 중간 삽입 삭제에 따라 유동적으로변해야한다면 변해야하는 시점에서 갱신해주면 자기 책임을 벗어나지않음.

[익명(183.100)]

id가 왜 변해 id는 할당한 순간부터 소멸되기 전까진 그 id가 Player객체를 가리키고 있음이 보장되어야 하는데 중간 삽입 삭제가 혹시 List얘기라면 List는 Find, Remove가 O(n)의 작업이여서 효율성이 부족함 그래서 Dictionary 써야한다고 계속 말했던거고 또 위에 말했듯 마지막 id의 ++을 해서 주는건 게임 규모가 크지 않고 싱글게임에 한해서 '거의' 안일어날수 있는 일은 맞음 근데 그게 멀티게임이나 게임을 극단적으로 오래 켜두면 가능한 일이지

[익명(183.100)]

아 지금보니까 List에서 Find는 인덱스 접근이니까 O(1)이네 ㅈㅅㅈㅅ Remove나 Insert의 경우 O(n)

[익명(14.42)]

걍 너가 그게 좋다싶으면 그렇게하셈. 너가 내말 납득안가는거처럼 나도 너가말하는거 이해안됌. 오버플로우얘기도 리스트 성능얘기도 그냥 반대를위한 억지부리는걸로만 느껴짐. idCount가 있고 없고랑 문제가 생기고 안생기고랑 상관이없을뿐더러 아그냥 상용게임들 프로그램들 뜯어봐도 그런식으로 안하고, 원론적인 얘기하는 기본서들에서도 하지말라는 행동임. 나는 내경험을 믿으니까 너도 너 경험을 믿으셈. 납득안갈 추상적인 얘기 길게해봐야 무의미한 키배만 길어질거임 별로유의미한 시간이 서로에게아닐듯

[익명(121.140)]

idCount를 'lastID'로 이름을 바꾸고(이름 이상했던 듯?), ScriptableObject의 uint 변수로 만들어서 따로 분리시켰엉(로컬 저장 되게), 전체적인 기능은 private Dictionary 를 들고 있는 DataManager(singleton)에 기능을 두었고, 외부에서 데이터가 필요할 때는 dictionary 에서 FindAll 해서 리스트로 추려서 리턴하는 public 메소드를 만들어 둠. 이제 2학년 해두 됨? ㅋㅋ 많이 배웠어 고마워

[익명(183.100)]

만약 List를 관리하고 싶은게 목적이라면 당연히 idCount도 숨기고 나머지 클래스들이 접근할때는 Get, Push, Remove함수를 구현해서 제공해주는게 정석이라고 생각하는데 그래야 나중에 유지보수도 편하고 한눈에 보기에도 좋을거 같음

[익명(121.140)]

많이 쓰는 기능일 것 같은데, Unity에 이미 만들어진 자료구조는 없는거야? 맨날 바퀴 또 만들고 또 만들고 해서 ㅜㅜ

[익명(183.100)]

근데 idCount까지 붙여가면서 플레이어리스트를 관리할꺼라면 많이 생성될거니까 만드는걸테고 그러면 List보단 Dictionary가 낫지 않음?

[익명(121.140)]

어 그렇네.. 고마워! 근데 어쨋거나 idCount는 dictionary 밖에서 관리해야 되는거니까 래핑해야 되는건 변함 없는거지?

[익명(183.100)]

많이 쓰인다고 해도 저렇게 만드는건 좀 보편적이라기보단 컨텐츠단 코드 느낌이 강해서 없지 않을까? 너가 게임에 맞춰서 원하는 동작들을 제공하는 함수에서 만들어야하잖아

[익명(183.100)]

그치 매니저가 private으로 들고있고 함수에서 조작하도록 해야겠지

[익명(211.197)]

id를 uuid로 생성하는 방법도 있음. 첫댓글 단사람 이상하네 id랑 index구분을 못하는거 같음 id를 숫자를 증가하는 방식으로 사용할경우 매니저가 안들고 있음 같은 id가진 객체가 생성될수밖에 없는데..