코딩 끝에 낙이 온다 코딩 끝에 낙이 온다

요소가 시간의 변화에 따라 변화하는 경우의 단점 프로그램을 이해하고 디버깅하기 힘들어짐 코드의 실행을 추론하기 어려워짐. 멀티스레드 프로그래밍의 경우 동기화가 필요하다 변경점이 많을 수록 충돌점이 많아진다. 테스트하기 어렵다 변경이 많을 수록 많은 조합을 테스트해야 한다. 상태 변경을 다른 부분에 알려야 할 때도 있다. 가변성 제한 방법 읽기 전용 프로퍼티(val) 완전히 변경 불가능하지 않다. 다른 프로퍼티를 활용하는 사용자 정의 게터로도 정의 가능하다. 정의 옆에 상태가 바로 적히므로 코드의 실행을 예측하는 것이 간단 스마트 캐스트를 활용 가능 가변 컬렉션과 읽기 전용 컬렉션 구분하기 읽기 전용 컬렉션을 가변 컬렉션으로 다운캐스팅하면 안 된다. 읽기 전용 컬렉션 사용 시 장점 한 번 정의된 상태가 유..

이전 글에서는 MVVM에 대한 대략적인 개념과 그것을 구현하기 위한 컴포넌트들에 대해 소개하였다. 이번에는 실제 코드를 통해 내가 MVVM을 어떻게 구현했는 지에 대해 보여주려고 한다. 내가 사이드 프로젝트로 시작한 어플에 MVVM을 적용했는데, 일반적으로는 Repository에 Room을 사용해서 내부데이터를 저장한다고 하지만, 내가 사용할 어플에서는 그 정도로 많은 양의 데이터를 저장할 필요가 없었고, 굳이 MVVM을 구현하기 위해서 Room을 사용하는 것 자체가 소 잡는데 닭 잡는 칼을 쓰는 모양새가 되는 것 같아서, 이전에 사용하던 SharedPreperence를 그대로 사용하기로 했다. 서버에 데이터를 요청하는 로직도 Model의 역할로서 같은 Repository에 포함시키도록 했다. objec..

내가 기존 회사에서 처음으로 시도해봤던 아키텍처 패턴은 MVP 패턴으로, 데이터 소스에 대한 접근은 Model이 담당하고, 사용자에게 데이터를 보여주는 부분(Activity,Fragment)는 View가 담당하며, 두 사이를 Presenter가 매개하는 형식의 패턴이라고 할 수 있다. 위 패턴을 직접 업무에서 적용하려고 했을 때 발생한 문제는 다음과 같았다. 일반적으로 View와 Presenter를 정의한 인터페이스인 Contract 등을 따로 정의해야 했고, 매번 두 아키텍처 컴포넌트를 변경해야 할 일이 생길 때마다 해당 인터페이스를 무조건적으로 변경해야 하므로 일을 두 번하게 되었다. View에는 데이터를 표시하는 일만 담당시키고, 복잡한 로직은 Presenter에게 위임시켜야 이상적인 MVP 패턴이..