[우협하] 재사용 View에 대한 고민

문제 인식

 회원가입 UI를 구현하는 과정에서 사용되는 여러 뷰컨트롤러마다 동일한 헤더뷰를 개별적으로 구현하는 방식으로 접근하였다. 이 방법은 처음에는 간단해 보였지만, 뷰컨트롤러가 늘어날 수록 동일한 구조의 커스텀 뷰가 반복적으로 생성되고 추가되는 상황이 발생했다.

 

 

 

 

1. 코드 중복 : 유사한 코드가 여러 곳에 반복되어 있다.

2. 유지보수의 어려움 : 헤더뷰의 변경사항이 생길 때마다 여러 파일을 수정해야 했다.

3. 확장성 부족 : 새로운 회원가입 단계를 추가할 때마다 새로운 헤더뷰 파일을 생성해야 했다.

 

해결 방법

 회원가입에서 사용할 공통 헤더뷰를 만들어 재사용할 수 있도록 했다.

 

1. 공통 헤더뷰 생성 : OnboardingHeaderView라는 클래스를 만들어 모든 회원가입 단계에서 재사용할 수 있도록 했다. 이제 각 뷰컨트롤러마다 새로운 헤더뷰 파일을 생성하지 않아도 된다.

 

2. 커스터마이징 가능한 속성 추가 : showLeftButton, showRightButton, rightButtonTitle, rightButtonTitleColor 등의 속성을 통해 각 화면에 맞게 헤더뷰를 쉽게 커스터마이징 할 수 있도록 했다.

 

3. 버튼 이벤트 처리 : OnboardingHeaderViewDelegate 프로토콜을 통해 버튼 탭 이벤트를 각 뷰컨트롤러에서 처리할 수 있도록 했다.

 

✏️ 헤더뷰의 기능에 따라 어떤 헤더뷰는 RightButton이 없기 때문에, RightButton의 Tap 이벤트는 구현하고 싶지 않았다. 즉, 델리게이트 프로토콜을 채택할 때, 모든 메소드를 구현하지 않고 일부만 구현하고 싶었다. 그러나 기본적인 Swift 프로토콜에서는 메소드가 옵셔널이 될 수 없으므로, 프로토콜에 @objc 속성을 붙여 Objective-C 호환 프로토콜로 만들고, 메소드를 @objc 옵셔널로 선언해야한다. 

 

하지만, Objective-C와의 호환성을 피하고 싶었고, 프로토콜 확장을 이용해서 기본 구현을 제공하여 구현하였다.

 

느낀점

1. 확장성 개선 : 새로운 회원가입 단계를 추가하더라도 기존 OnboardingHeaderView를 그대로 사용할 수 있어 확장성이 크게 개선되었다.

2. 코드 재사용의 중요성 : 재사용 가능한 컴포넌트를 만드는 것이 장기적으로 개발 시간을 단축시키고 코드 품질을 향상시킨다는 것을 느꼈다.

3. 유지보수의 용이성 : 헤더뷰의 디자인이나 기능을 변경해야할 때, 한 곳만 수정하면 되므로 유지보수가 휠씬 쉬워졌다.