4.19 현재 뜯어고치고 싶은 아쉬운 부분들...

모듈과 클래스를 넘나들면서 사용될 여지가 있는 한가지 객체,의미,숫자는 최하단 모듈에 정의해놓고 어디서든 사용할 수 있도록 조금씩 수정해왔다.

현재 BLUECELL,REDCELL,SIGNAL,S_ESC,B_ESC와 GameConfig객체등이 리팩토링 과정을 통해서 생겼고, 덕분에 True나 1,2같은 알수 없는 의미의 객체로 "말이 되야 할"코드를 오염시킬 일이 많이 사라졌다.

하지만 eye객체는 절대상수화(?)가 매우 까다로운 상태에 놓여있다. eye의 경우 많은 정보를 필요로 하기 때문에 상위 모듈에서 상위 객체들을 통해 정보를 얻어서 생성되야 한다.

이 때문에 많은 함수와 클래스들로 eye객체가 팬아웃되면서 쓸데없이 엄청 많은 레퍼런스 카운트를 짊어진데다가 함수 파이프라인을 연결 해줘야만 사용할 수 있는 까다로운 상황에 놓이게 되었다.

lambda: None에 대해서도 불만이 많다. 하위 로직이 변수를 Callable하다고 가정할 때 default인자를 None으로 하지 못해서 lambda:None을 사용하고 있다. 이 쓸데없는 람다식을 하위 모듈에서 상수로 만들어 놓고 재활용하는게 마음피 편할꺼같아도 상수로 만들어봤자 lambda:None보다 직관적인 표현이 안떠오르는 데다가, 퍼포먼스 저하의 미세한 요인이 될 수 있다는 점이 불편해서 그냥 람다식으로 사용하고 있다.

ui관련 객체가 가지고 있는 destroy편의 함수도 불편하다. ui들이 자신을 제거할때 다들 유사한 방식을 사용한다. 클래스에 포함된 각종 Entity들을 제거하고, 3D환경에서 컨트롤러(Eye)를 잠구고 마우스를 켰다면 그것을 다시 복구시킨다. 코드를 보면 반복적으로 destroy를 호출하고, 커서를 켜고 끄는 코드도 거의 비슷한것이 반복 작성되고있다. 심지어 이 destory함수는 특정 객체에서 "종료자"역할을 한다. 다시말해서 해당 객체가 제거된 이후 실행될 함수를 함께 가지고 있다는것이다(destory에 대한 의미오염). 그럼에도 객체들의 구조가 미묘하게 달라서 공유할 하나의 함수를 설계할 엄두를 내지 못하고 있다. 게다가 destroy를 "종료자"처럼 사용하는것에 익숙해져서 Ursina라이브러리에 포함된 destory함수와 조금 다른 obj.destroy가 불어나서 코드가 난해해질까봐 걱정된다.

마지막으로 import * 가 과용되고 있는게 아닐까 걱정된다. 사실 core모듈 내부에서는 상위 모듈이 하위모듈의 모든것을 사용할 수 있는 구조로 설계 한 뒤, core외부에서 core.obj 형식으로 사용할 수 있도록 할 계획이었다. 하지만 core외부는 프로세스 관리나 캐시,큐 이런것 때문에 여유가 없었고 결국 외부에서는 core에 대해서 "모든것"을 시작시키는 트리거 함수만 실행시키고 있다. 다행히도 변수가 겹치는 상황은 없지만 각 모듈에서 코드의 의미를 확실하게 표현하지 못한다는 점이 아쉽다. 도트 연산자가 모듈구조를 표현해주지 못하니까 모듈화가 잘 된건지 주기적으로 평가할수가 없다. clien/core/artifacts/origin에 있는 main,setting,tools 각 모듈이 올바른 의미로 잘 묶였는지 확신할 수가 없다. 상위 모듈에서는 항상 from .origin import * 만 사용하니까 뭐가 정확히 어디들어있는지도 신경쓸 필요가 없어졌다. core모듈을 벗어나서는 조금 더 "말이 되는"코드가 작성되도록 모듈설계를 해야겠다.

추가로 Entity를 상속받은 클래스를 init할때는 super().init()이 자동으로 호출되는 메타클래스를 만들거나,매우 유연한 base클래스들을 만들어서 조금만 연관성 있는 클래스라면 모조리 상속받아서 사용할 수 있도록 할껄 하는 생각이 있다. 하지만 이런건 OOP구조가 갖춰지기 전에는 필요성을 알아채기 힘들다고 생각하고, 당장 불편한점은 없다.