정책은 키벨류 형식으로 돼있는데 키의 종류에 따라 클래스를 나눴음.
키는 용도에 따른 큰 구분은 있지만(A정책과 관련된 키, B정책과 관련된 키 등), 각 정책별로 요구하는 데이터는 다 다름.
type, name, data 이렇게 일관성이 있는게 아니라 정책에서 필요로 하는게 각자 전혀 달라서 클래스를 이렇게밖에 못 나눴음
대략 사진에 있는 모습처럼 구성했는데 뭔가 Getter 를 안 좋게 남발하는건 아닌가 싶더라고
이런 유형에서 적용했을때 효율적으로 구조를 개선할 수 있는 디자인 패턴이 있어?
원래는 그냥 키 벨류 쌍을 해시맵에 전부 때려넣고 쓰는게 훨씬 코드가 덜 복잡할 거라고 생각했는데 몇가지 단점이 생각나더라고 1. 조회가 많이 일어나면 성능이 나쁘지 않을까 싶음 2. 알고 있는 모든 키 문자열을 상수든 매크로든 선언을 해야 일관성 있게 여러 곳에서 조회 가능할 것 같은데 이러면 저 방식과 다른게 뭔가 싶음
3. 키 조회해서 획득한 값을 정수, 실수, 부울리언, 문자열 중에서 어떤 형식으로 받아야 하는지에 대한 규칙이 없어서 다른 사람이 잘못 사용할 가능성
1. 코드에서 인터페이스를 활용하는 부분이 안보이는데, 왜 쓰는지? 성능을 걱정한다고 했는데, 가상함수 사용에의한 성능저하는 괜찮은것인가?
가상함수가 성능상 더 떨어질려나 벤치마크를 해봐야겠네
2. 각 폴리시키에 대한 데이터(타입, 갯수 모두 다른) 마다 구조체 만들고 템플릿 쓰면 안되나? template T& GetDataByPolicyKey(const std::string& key) { void* data = policy.get(key); return reinterprete_cast(*data); }
키:데이터 쌍이 종류가 백개가 넘어가는데 매크로로 구조체 생성 자동화 해버리면 되나
근데 보니까 이렇게 하려면 해시맵에 들어갈 키의 데이터값은 전부 힙할당이 돼야하잖아 힙할당은 확실히 느려질 것 같은데 힙할당을 안 하면 varint 외에는 타입 여러개를 담을 수가 없고 variant 로 묶자니 묶어야할게 한두개가 아니고 굳이 variant 까지 사용해서 해시맵으로 바꿔야할까 싶고
근데 해시맵을 안 쓰면 반대로 게터 함수가 최악의 경우 키 개수만큼 필요하니까 (물론 가공해서 합칠 수 있는 부분도 있어서 이정도까진 아니긴 하지만 엄청나게 많긴 함) 이것도 문제네..
힙할당이 느리겠지만, 처음 초기화할때 빼고는 new안쓰잖아
엇 std::variant로 커버되면 이거쓰셈 ㅋㅋ 아 근데, 똑같은 문자열이라도 의미가 다르니 좀 그렇네.
괄호는 사라졌는데 T가 들어감.
어쨌든 해시맵에 담는게 더 좋을 것 같다는 말이지? 키가 몇 개 안되면 별 걱정도 안 하는데 대략 150개의 키가 존재해서 구조체에 각 멤버변수 만드는 것도 엄청난 노가다였음
ㅇㅇㅋ. 150개인데 뭐 속도따진자고 다 클래스로 만들고 직접호출하는건 너무 속도지향적인 것 같은데... 만약에 프그램에서 해당 함수들이 초당 뭐 수천 번 호출되면 모를까
그리고 그 정도면, 스크립트 하나 만들어서 키에 따라 구조체 만드는거 자동화하셈. 구조체 150개가 한 헤더에 스크립트에 따라 만들어지는거지. 그리고 빌드할때 자동실행되게 하면 되넹
ㄴㄴ 키 150개라고 클래스가 150개인게 아니라 한 클래스에 멤버 변수 150개 박는건 미련해 보여서 내가 그냥 의미에 따라 대충 5가지로 분류해서 그 다섯개 클래스에 나눠서 파싱시켰었음