Skip to content

97JUN/BeTime

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 

Repository files navigation

BeTime

<요약>

사용자의 위치 기준에 따라 1시간마다 최신으로 업데이트된 데이터를 기반으로 날씨(기온, 강수확률)을 제공하고 사용자가 원하는 지역의 대한 날씨(기온,강수확률)을 제공한다.

<제작 배경>

기존 날씨 앱보다 더 최신화 되어 보다 정확한 날씨 데이터를 사용자에게 제공하려고 합니다.

<사용 아키텍처>

Clean Architecture

크게 Presenter Layer, Domain Layer, Data Layer로 구성하였습니다.

각각 수행하는 역할은

  • Presenter: 사용자의 이벤트를 전달받고 View 업데이트, 상태관리
  • Domain: 비즈니스 로직을 담당, 비즈니스 핵심 모델 보유
  • Data: API를 통해 서버로 부터 날씨 데이터 요청.

<앱 화면 구성>

<프로젝트 설계와 구현에서 배운 점>

클린 아키텍처를 통해 유지 보수성 향상, 테스트 용이성

이 프로젝트에서 가장 어려웠던 문제는 클린 아키텍처를 처음 도입하면서 각 객체의 역할을 명확히 나누고, 레이어 간의 결합도를 낮추는 설계 방법을 이해하고 적용하는 것이였습니다. 특히 Scene, Domain, Data 레이어 중 Domain, Data 레이어를 나누는 과정에서 어느 레이어가 어떤 책임을 가져야 할지 고민이 많았습니다. 이를 해결하기 위해 클린 아키텍처와 관련된 자료를 학습하고, 이를 통해 각 레이어의 역할을 명확히 정의하는 설계를 도출했습니다.

이러한 설계 방식을 적용한 후, 각 레이어의 결합도가 낮아지면서 유지보수성이 크게 향상되었습니다. 새로운 기능 추가나 기존 기능의 수정 시 해당 레이어만 수정하면 되도록 하여, 코드의 안정성을 높였으면, 변경 사항이 다른 부분에 영향을 미치지 않도록 설계하였습니다.

또한, 테스트 용이성을 높이기 위해 각 레이어를 독립적으로 테스트할 수 있는 구조로 설계했습니다. 이로 인해 UseCase 테스트 시 Repository 객체의 Mock 객체를 생성하고, XCTest를 통해 날씨 데이터를 요청했을때 올바르게 요청되었는지 와 올바른 데이터를 반환하는지 검증할 수 있었습니다. 이를통해 특정 기능이 다른 객체에 영향을 받지 않으면서도 손쉽게 테스트할 수 있었습니다.

Swinject를 통한 의존성 관리

Swinject를 사용하여 의존성을 DIContainer 한 곳에서 관리할 수 있기 때문에, 애플리케이션 전반에서 생성과 관리해야 하는 객체들을 일관되게 처리할 수 있습니다.이를 통해 불필요한 객체 생성을 줄이고 메모리 관리를 최적화할 수 있도록하여 필요한 시점에 객체를 주입받도록 하여 코드의 간결성을 높이고 유지보수성 또한 높히도록 노력했습니다. 또한 ViewController 생성시 Factory 패턴을 사용하여 각 Scene의 의존성을 명시적으로 관리하도록 구현하여 유지보수성을 높일 수 있었습니다.

의존성 주입을 구현할 때, 가장 어려웠던 점은 Interactor, UseCase, Repository 간의 관계 설정이었습니다. Interactor는 UseCase와 Repository를 필요로 하지만, 각각의 의존성을 어떻게 관리할 지 고민이였습니다. Swinject를 활용하면서 매번 새로 생성해야 할 의존성과 한 번만 생성해도 되는 의존성을 구분하는 방법을 학습했습니다. 상태를 유지할 필요가 없거나, 특정 작업에서만 필요한 객체들은 호출 시 새로 생성하도록 설정하였고, 한번 생성되면 여러 번 재사용되거나, 한 번만 생성해도 충분히 애플리케이션 전반에 사용할 수 있는 객체는 Container에 저장하여 사용하도록 처리했습니다. 이를 통해 객체의 생성 및 관리를 일관되게 처리하는 설계를 도입할 수 있었고 코드의 유지보수성과 가독성을 개선할 수 있었습니다.

ViewController 생성 방법에 대한 고민

ViewController를 생성하는 방법에 대해 빌더 패턴과 팩토리 패턴 중 어떤 것을 사용할지를 고민하는 과정에서, 가장 어려웠던 점은 각 패턴의 적합성을 평가하는 것이었습니다. 특히 동일한 UseCase를 사용하는 경우에도 UI 요소를 나타내는 Presentation 객체를 반환하는 점에서 두 패턴 간의 차이가 크지 않았습니다.

ViewController는 1대 1 매칭이 불가피하여 Scene 단위로 나누는 것이 필요했기 때문에, 팩토리 패턴을 적용하게 되었습니다. 팩토리 패턴을 통해 각 Scene의 의존성을 명시적으로 관리할 수 있으며, 이를 통해 유지보수성을 크게 향상시킬 수 있었습니다.

이 과정을 통해 의존성 주입의 중요성을 깨닫게 되었고, 각 View에 필요한 의존성을 구조체를 통해 효과적으로 관리하는 방법을 이해하게 되었습니다. 결과적으로 ViewController를 생성하는 방법을 일관되게 관리할 수 있는 기반을 마련하게 되었습니다.

About

실시간 날씨를 조회하는 날씨 앱

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •