Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- 애니메이션
- 리펙토링
- MVVM
- 클린 코드
- ribs
- tableView
- clean architecture
- 스위프트
- ios
- uitableview
- 리펙터링
- 리팩토링
- HIG
- Clean Code
- combine
- swiftUI
- Xcode
- RxCocoa
- Protocol
- UITextView
- Refactoring
- Human interface guide
- map
- uiscrollview
- UICollectionView
- collectionview
- swift documentation
- SWIFT
- rxswift
- Observable
Archives
- Today
- Total
김종권의 iOS 앱 개발 알아가기
[iOS - swift] 튜플을 활용한 리펙터링 (tuple refactoring, 튜플 리턴) 본문
Refactoring (리펙토링)
[iOS - swift] 튜플을 활용한 리펙터링 (tuple refactoring, 튜플 리턴)
jake-kim 2023. 11. 29. 01:48튜플 리턴 리펙터링
- 보통 특정 함수에서 return 타입이 하나인 경우가 대다수
- UIView에서도 frame값을 가져오는 메서드의 리턴타입이 CGRect하나
- 경우에 따라서는 return 타입을 튜플로 만들고 튜플에서, 사용하는쪽에 필요한 정보를 같이 넘기게하면 유용한 코드 유지가 가능
Bool타입과 같이 튜플형태로 리턴하기
- 특정 메서드에서 일을 수행한 후 그 결과를 사용하는쪽에 넘겨주는데 이 때, 튜플형태로 Bool 타입과 같이 넘겨주면 사용하는쪽에서 더욱 이해하기 쉽고 사용하기 쉬운코드 유지가 가능
- ex) 메서드를 사용하는쪽에서 그 메서드의 결과로 인해 true or false를 판단하여 일을 수행해야하는 경우, 사용하는쪽에서 true or false를 구분짓지 말고 메서드에서 Bool타입과 같이 리턴하는 튜플형태로 구현
ex) Car 클래스
- 자동차 인스턴스가 chargeForFix를 얻어서 특정 일을 수행해야하는 경우
class Car {
var brand: String
var model: String
var year: Int
init(brand: String, model: String, year: Int) {
self.brand = brand
self.model = model
self.year = year
}
func drive() {
print("Driving \(brand) \(model)...")
}
func chargeForFix() -> Int {
(0...10).randomElement()!
}
}
(사용하는쪽)
- chargeForFix() 결과로 특정 분기문이 들어가는 형태
let car = Car(brand: "tesla", model: "model y", year: 2023)
if car.chargeForFix() == 0 {
print("무료로 수리 혹은 수리할곳이 없음")
} else {
print("유료로 수리")
}
- chargeForFix()를 사용하는 쪽에서 true or false를 판단하지 않고, Car 인스턴스에서 판단하여 튜플을 리턴해주도록 리펙터링
- 사용하는 쪽에서는 결국 fixed와 chargingPrice만 보고도 chargeForFix()의 메서드 역할이 명확하고 사용하기도 간편한 구조
let (fixed, chargingPrice) = car.chargeForFix()
if fixed {
print("수리됨", chargingPrice)
} else {
print("수리 x", chargingPrice)
}
정리
- 개발자는 메서드의 내부를 보기전에 먼저 사용하는쪽을 먼저 보게되고, 보게될때 메서드를 타고 들어가서 확인하기 전에 예측하기 쉬운 코드이면 코드의 가독성이 증가
- 코드가 예측하기 쉬울려면 사용하는 쪽의 코드에서 가능한 로직이 적게 있어야함
- 튜플을 리턴해주면 사용하는쪽에서 로직이 적게 유지할 수 있고, 튜플을 리턴해주는 메서드에서 그와 연관된 로직도 같이 메서드에 담겨들어가 더욱 응집력 있는 코드 관리가 가능
'Refactoring (리펙토링)' 카테고리의 다른 글
[iOS - swift] 프로토콜로 리펙토링하기 (5) | 2024.01.05 |
---|---|
[iOS - swift] 예외처리로 리펙토링하기 (throw, try, catch) (2) | 2023.12.17 |
[Refactoring] 메서드와 함수의 파라미터 리펙토링 (0) | 2023.11.19 |
[iOS - swift] 표현식을 이용한 조건문, 삼항 연산자, switch - enum 리펙터링 (Swift5.9) (3) | 2023.11.10 |
[iOS - swift] 2. weak self 동작 이해하기 - 외부에 weak self 선언하고 클로저에서 사용하는 경우 (#캡처리스트 [weak self] 리펙토링) (0) | 2023.11.05 |
Comments