[Refactor] #625 - FeedViewModel로 FeedVC 리팩토링

[yangsubinn]

🔥Pull requests

⛳️ 작업한 브랜치

• refactor/#625

👷 작업한 내용

데이터를 담는 리스트와 리스트를 수정하는 부분은 최대한 다 FeedViewModel 로 옮겨서 그 안에서만 수정하도록 했습니다...

🚨참고 사항

생각보다 많이 엉망이었던 것 같아요.. 일단 목표는 리스트를 수정하는 부분은 전부 viewModel에서만 처리하도록 하는 것이었고 아마.. 전부 수정한 것 같습니다.. 근데 이게 맞는지도 확실히 모르겠고 , 보다보니 너어무 리스트가 많은 것 같아서 이것도 바꾸긴 해야할 것 같은데 .. 일단 더 좋은 방법이 있다면 .. 듣고자 먼저 풀리퀘 올려봅니다 .. 질문.. 태클.. 조언 .. 전부 다 받습니다 ..!

📟 관련 이슈

• Resolved: #625

[yangsubinn]

이슈발생.. 했응께 좀만 다시 수정하고 다시 태그해드리겠습니다.. 그때 봐주세요..😇 @hyun99999 @L-j-h-c

[yangsubinn]

수정했습니다 확인부탁드립니다 🤓 @hyun99999 @L-j-h-c 저거보다 더 좋은 방법이 있을 것 같긴한데 일단.. 생각이 안나

[yangsubinn]

워후 확실히 전보다 훨씬 보기 좋아졌네요!! 수고 많으셨습니다~~! 한 가지 궁금한 점은 뷰모델에 타입 프로퍼티를 두고 접근하신 부분이에요!! 보통은 뷰컨트롤러 안에 뷰모델을 두고 쓰는데, 그렇게 하면 뷰컨트롤러가 메모리에서 해제될 때 뷰모델도 해제될 수 있기 때문에... 그렇게 쓰지 않나 싶은데 이렇게 shared로 접근하는 건 처음봐서요!!

일단 shared로 접근한건 제가 저 친구를 싱글톤 패턴의 Manager 파일을 참조해서 만들다가 그런 것 같아여..! 같은 데이터를 필요로 하는 여러 뷰컨에서 하나의 manager에 모든 데이터를 보관하고 그 데이터를 여러 곳에서 수정하기 때문에 여기서도 FeedViewModel 안에 타입 프로퍼티로 FeedViewModel 인스턴스를 만들어서 여러 뷰컨에서 접근하더라도 하나의 인스턴스를 사용하겠다는 의미였슴니다

여기서 갖고 있는 데이터가 다른 뷰컨에서 쓰일 일이 지금은 없긴 하지만,, 만일 나중에라도 다른 곳에서 수정될 일이 생긴다면 메모리 관리하는 면에서도 최초 한번 하나의 인스턴스로 만들어두고 같은 데이터를 수정한다는 점에서 두는 것도 나뿌지 않을랑가 싶어요 ..

[yangsubinn]

@L-j-h-c @hyun99999 록시선배 코드리뷰 반영해서 배열 안의 배열 형태로 수정했슴니다 ! 코드가 훠어어어얼씬 깔끔해졌어요 ! 그리고 방금 배열 안의 배열로 수정하면서 조그만하게 느낀 부분이 ,, FeedViewModel로 배열 관련 로직을 전부 분리해뒀더니 정말 딱 요 파일만 수정하게 돼서 먼가 잘 분리되었다는 .. 느낌이 들었습니다.. 아님 말고 .. 로직은 FeedViewModel에서 처리하고, 처리한 결과의 최종 배열만 VC로 전달하고 .. 그러려고 했습니다

깔꼼하고 뿌듯한 기분은 제가 오랜만에 개발을 해서일까여 .. 🥹

[L-j-h-c]

@L-j-h-c @hyun99999 록시선배 코드리뷰 반영해서 배열 안의 배열 형태로 수정했슴니다 ! 코드가 훠어어어얼씬 깔끔해졌어요 ! 그리고 방금 배열 안의 배열로 수정하면서 조그만하게 느낀 부분이 ,, FeedViewModel로 배열 관련 로직을 전부 분리해뒀더니 정말 딱 요 파일만 수정하게 돼서 먼가 잘 분리되었다는 .. 느낌이 들었습니다.. 아님 말고 .. 로직은 FeedViewModel에서 처리하고, 처리한 결과의 최종 배열만 VC로 전달하고 .. 그러려고 했습니다

깔꼼하고 뿌듯한 기분은 제가 오랜만에 개발을 해서일까여 .. 🥹

오오오 코드가 확실히 줄었네요...이걸 이렇게 뚝딱 해버리시다니 멋져요!! 앱을 점점 Develop 시키면서 규모도 커지고 하면 유지보수를 해야할 일이 많아질 것 같은데 큰맘먹고 ViewModel로 리팩하신 부분...멋있습니다..난 언제 보관함 리팩하냐고 아 ㅋㅋ 아니 글고 왜 개발 오랜만이냐고 ㅋㅋ

[hyun99999]

view model 에 대해서 싱글톤 패턴 사용 수빈선배가 말한대로 싱글톤 패턴을 사용하면 혹여나 다른 뷰에서 사용할 때 메모리를 아낄 수 있을거 같아요! 또한, view model 과 view 는 1:N 의 가능하기 때문에 뷰 모델을 수빈선배가 말한대로 공유할 여지는 있다고 생각해요! 이때의 단점은 뷰모델이 커질 수도 있다가 있을거 같아요. 반면에 싱글톤 패턴이기 때문에 준호선배 말한대로 뷰 컨트롤러가 메모리에서 해제될 때 뷰 모델이 해제되지 않기 때문에 불필요한 메모리를 잡고 있을 수도 있다고 생각해용. 또한, 싱글톤 패턴의 단점은 멀티스레드에서 같은 인스턴스에 대해서 동시에 접근하여 동기화 문제와 자원에 대한 병목 현상도 있다고 존재해용. 그래서 굳이 뷰에 대해서 뷰 모델이 유효한 것이지 다른 경우에도 필요한 것이 아닌데 싱글톤을 사용하는 것은 장점을 잘 살리는 방법은 아니기 때문에 단점이 먼저 보일 수도 있는 것 같아요! 그냥 단순하게 다른 뷰에서도 사용하게 된다면? 그냥 뷰 모델을 공유하는 것이지요

요 글도 참고해 보면 좋을거 같아요!

https://velog.io/@cherish307/Why-should-ViewModel-not-be-Singleton-Object

[yangsubinn]

@L-j-h-c @hyun99999 코드리뷰 반영해서 전부 수정했슴니다 머지할게여 !