원안은 관련 매니저에서 거의 모든 처리를 하는거였음


UI뷰에서 유저입력이 들어와서 데이터 처리가 필요할때 매니저를 호출하면


매니저가 자신이 소유한 데이터를 훑으면서 데이터를 조작하는 형태




근데 데이터 종류가 많아지면서 매니저 처리파트의 if/switch 부피가 너무 커졌고


결정적으로 확장성이 너무 떨어진다고 판단했음. 데이터 타입을 추가할때마다 매니저의 if/switch 파트를 한바퀴씩 다 돌면서 만져야되니


그래서 데이터 조작은 데이터 클래스가 내부적으로 하도록 인터페이스로 쫙 묶어서 데이터 안쪽으로 빼고


새 데이터 타입 추가시 새 데이터 클래스 만들고 인터페이스만 구현하는게 의존성 측면에서 훨씬 낫겠다 싶어서 리팩토링을 진행함





그랬더니 매니저에서 내부처리에 쓰던 스태틱 유틸함수들이 외부에서 필요해지기 시작함


일단 필요할때마다 퍼블릭으로 바꾸기만 해서 위치는 그대로 매니저 안쪽인데 어차피 매니저 내부에서 쓸 함수가 아닌데 이걸 매니저가 굳이 들고있을 필요가 있나 싶은거


그래서 그 유틸함수들도 별도 스태틱 클래스를 만들어서 빼려고 함.


여기서 의문이 그럼 매니저의 역할이 남은게 거의 없네?





데이터 조작을 위한 최초 호출 -> 매니저에서 들어가긴 함


내부 처리 -> 데이터 모델에 구현된 인터페이스가 함


내부 처리에 필요한 부수 계산들 -> 매니저에서 떨어져나갈 예정인 유틸 클래스가 함


매니저는 그럼 사실상 최초요청시 한번 들르기만 하는 호출기가 되어버리는데 이게 원래 맞는건가?


그리고 매니저가 아닌 모델이 계산 논리를 들고있어도 괜찮은거임? 이게 오히려 유지보수 측면에서는 중앙화가 안되니까 리팩터링 전보다 더 독이 되지 않을까 걱정인데