Day 20 - TIL
코드설계 할 때 Controller의 과도한 의존성 이슈 및 프로퍼티
Day 20 - TIL
📘 Day 20 - Today I Learned
## 🔍 Today Error or Issues
Issues : 개인과제에 Controller에 로직이 과도하게 집중됨
뷰와 컨트롤러 간의 역할 분리가 부족하고, 메시지 관련 로직이 Controller 내부에 혼합되어 있음
🛠️ Troubleshooting
- 메시지를 처리하는 전용
MessageController
생성 제안 - Controller에서 너무 많은 역할을 수행하지 않도록 분리
- 컨트롤러는 모델 데이터를 전달하는 역할만,
뷰는 해당 데이터를 받아 UI로 표현하도록 구조 리팩토링 - 반복문에서는 인덱스의 절대값보다는 상대값 활용
- 옵셔널 체이닝에서는
map
,flatMap
활용을 고려
📝 Learning Summary
✅ 프로퍼티 (Property)
저장 프로퍼티
값을 저장하는 일반적인 프로퍼티
enum
에서는 사용할 수 없다연산 프로퍼티
값을 저장하지 않고 계산하여 반환하는 프로퍼티
var
만 사용 가능 (let
은 계산 불가)타입 프로퍼티
모든 인스턴스에서 공유하는 프로퍼티
static
키워드를 사용하며 타입 자체에서 접근 가능프로퍼티 옵저버
값이 변경되기 전과 후에 코드 실행 가능 (willSet
,didSet
)지연 저장 프로퍼티 (
lazy
)
처음 사용될 때 초기화되는 저장 프로퍼티
인스턴스 생성 비용을 줄일 수 있음
📘 Lesson Learned
이번 코드 리뷰를 통해 하나의 컨트롤러에 너무 많은 책임이 집중되어 있다는 점을 알게 되었다.
기능에 따라 로직을 분리하고, 역할을 명확하게 구분하는 것이 유지보수성과 협업에 얼마나 중요한지 체감했다.
또한 Optional
처리에서 map
, flatMap
을 활용하는 방식이나 반복문 인덱스 사용에서도 작은 습관이 가독성과 코드 품질을 좌우할 수 있음을 느꼈다.
다음부터는 구조 설계 단계부터 충분히 고민하고, 역할에 맞는 책임을 분산시키는 개발을 지향해야겠다.
This post is licensed under CC BY 4.0 by the author.