작성
·
187
답변 1
1
수강해주셔서 감사합니다.
맞습니다. C++ 같은 언어에서는 friend Keyword를 통해서 private 변수에 접근이 가능하지만 C#에서는 그 방법이 없으므로 보통 Reflection을 통해 은닉성을 지키면서 수정을 가합니다. 다만 이는 IODatabase가 IO 객체를 관리한다는 명확한 상하관계에 놓여있기 때문에 택한 방식으로 Reflection의 무분별한 남용은 또 다른 은닉성의 파괴로 이어지게 됩니다.
감사합니다.
강사님 추가적인 질문이 있어서 여쭤봅니다.
은닉성을 지키기위해서 리플렉션을 이용해서 값을 대입하셨는데, 코드에서는 IdentifiedObject의 필드들에 대응되는 pulbic 프로퍼티들 있지 않나요?
이들을 사용해서 값을 대입하는 것도 은닉성을 지켜준다고 볼 수 있지 않을까요? 이 프로퍼티를 사용하지 않고 대신 리플렉션을 사용하신 이유를 알고싶습니다.
이는 '안정성'의 문제입니다.
은닉성을 지켜야하는 이유 중 하나는 개발자가 변수를 잘못 사용하는 실수를 막기 위해서입니다. 팀 작업을 해보시면 루키 프로그래머들이 변수 하나를 잘못 써서 하루 종일 디버깅 하는 모습을 보는게 꽤 흔합니다.
아시다싶이 현재 IO객체의 변수들은 getter만 만들어져 있는 상태입니다. IO 객체의 기초 변수들은 오직 Tool을 이용해서만 편집하는 것을 제가 규칙으로 정했기 때문입니다. 물론 개발을 하다보면 IO 객체의 변수들을 수정해야할 필요가 있을 수도 있습니다. 하지만 설정해둔 Data의 ID와 CodeName을 Runtime Code를 통해 바꾸는게 '절대' 일반적인 경우는 아닐겁니다. 이미 Tool을 통해 다 설정해둔걸 굳이 건드려야할 이유가 보통은 없을테니까요.
id 변수를 수정할 수 있는 Setter를 만들었다고 가정을 해보겠습니다. 자신 혹은 개발 팀원 중 누군가 ID Property를 다루다 실수로 의도치않게 ID Property에 이상한 값을 대입하게 된다면(예를 들어, IDE의 Code 자동 완성 기능을 쓰다 실수로 ID에 값을 대입하고 인지 못한 경우), 이후 ID를 비교하는 과정에서 문제가 생길 것이고, 이를 모르는 누군가는 어디서 터진 버그인지 찾기 위해 하루종일 디버깅을 할 수도 있습니다. 그리고 누군가 실수로 'ID' 값을 바꿔서 생긴 문제라는걸 알고 허탈해하겠죠.
Reflection을 사용하게되면 Reflection Code를 작성해야하는만큼 실수로 'id' 값을 바꿨다는 문제가 생길 확률이 상당히 낮아지게 됩니다. 종합하면 Reflection을 쓴건 누군가 보통은 '바꿀 이유가 없는 id'를 '실수'로 바꿔서 생길 문제를 방지하는 측면이라고 생각하시면 됩니다.
Unreal Engine을 사용하면 다루게 될 C++의 friend Keyword도 마찬가지입니다. 다른 class의 private 변수에 접근할 수 있게 해주는 이 Keyword는 남용하면 안되지만, 위와 같은 이유로 은닉성을 지키기 싶을 때 한정적으로 사용하게 됩니다.
다만, 위에서 말씀드렸듯이 이는 그저 제가 만든 규칙일뿐입니다. 'ID와 CodeName을 Code를 통해 수정하는 것이 일반적일 수 있는 경우다' 혹은 '굳이?'라는 생각이 드신다면 Reflection을 사용하지 않고 Setter를 만들어 사용하셔도 상관이 없습니다. Setter를 만드시는 분들 중에는 이렇게 중요도가 높은 변수는 Property가 아닌 SetID(int id) 식으로 함수를 만드셔서 실수를 최대한 방지하시는 분들도 존재합니다. 저는 좀 더 엄격히 은닉성 지킨 것이고, 함수를 만드시는 분들은 좀 더 느슨한 방식을 취하시는거죠. '실수 방지'에 초점을 맞췄다는 점에선 같습니다.
Coding Convention이라는건 혼자 개발할 때는 자기에게 맞춰지고, 팀에서는 팀 내부 Convention을 따라가는 것이기 때문에 '이런 식으로 생각하는 프로그래머들도 있다' 정도로만 생각하시면 될 것 같습니다.
감사합니다.
답변 감사합니다