김종권의 iOS 앱 개발 알아가기

서브 클래스를 델리게이트로 바꾸기 특정 타입에 따라 동작이 달라지는 경우, 주로 enum case로 분기하여 구현하지만 저번시간에 알아본대로(이전 글 참고) 상속 관계를 만들면 SRP를 지키면서 더욱 유지보수 하기 쉽게 코드 관리가 가능 공통 코드는 수퍼클래스가 책임지고, 각각의 기능은 서브클래스로 정의하여 각 하나의 역할을 담당하도록 구현하는 것 이처럼 서브 클래스의 장점도 많지만, 단점이 존재 단점1) 수퍼클래스와 서브클래스간의 결합도가 증가하여 부모를 수정하면 자식들의 기능을 헤칠 수 있음 단점2) 사람 객체의 동작이 나이대와 소득 수준으로 나뉜다면, 서브클래스를 부자와 서민으로 나눌 것인데 이렇게 된다면 각 서브클래스에서 하나의 인스턴스로 두 기능 모두 사용이 불가능한 상태 서브 클래스를 델리게이..

메서드 올리기 서브클래스들이 여러개 있을 때 이 클래스에서 동일한 내용을 정의하는 메서드가 있을 때 이 메서드를 수퍼클래스에 이동시켜서 중복을 제거할 수 있음 중복의 위험) 동일한 로직을 사용하고 있는 중복 코드에서, 한쪽의 변경이 다른 쪽에는 반영이 안되는 이슈가 발생할 수 있는 가능성 존재 예시) 메서드 올리기 Member라는 수퍼 클래스가 있고 서브 클래스로 Developer, FireFighter가 존재 얼핏보면 메서드 이름이 달라서 다른 메서드인것 같지만 같은 역할을 하는 것이므로 getFullname(), getName()을 하나로하여 수퍼 클래스로 이동이 필요 class Member { var age: Int var name: String init(age: Int, name: String) ..

오류 코드를 예외로 바꾸기 하드코딩된 상수인 매직 넘버를 사용하여 오류처리를 하는 경우가 있는데, 매직 넘버를 사용하면 의미나 목적을 이해할 수 없으므로 매직 넘버를 사용하면 안좋고 예외로 바꾸어야함 ex) 매직 넘버 예시 // 매직 넘버를 사용한 예시 func calculateAreaOfCircle(radius: Double) -> Double { return 3.14159 * radius * radius } // 매직 넘버를 상수로 대체 let pi = 3.14159 func calculateAreaOfCircle(radius: Double) -> Double { return pi * radius * radius } ex) 예외 처리를 하지 않은 오류 enum FetchItemType: CaseIte..

cf) 파생과 질의 구분하기 파생(Derived) 변수: 사용하는쪽에서 관심 밖의 변수들에도 영향을 주는 것 질의(Query) 함수: 사용하는쪽에서 관심 대상인 변수에만 영향을 주는 것 (단순 get, set) 매개변수를 질의 함수로 바꾸기 함수의 동작에 변화를 주는 요인은 함수의 매개변수 즉, 함수의 동작에 변화를 주는 요인을 구성할 때 짧으면 짧을수록 이해하기가 쉬운 형태의 함수 함수가 스스로 쉽게 결정할 수 있는 값을 매개변수로 건네는 것도 일종의 중복이므로, 이 결정은 함수안에서 결정하게하여 더욱 간결한 함수형태로 변경이 필요 ex) 함수를 사용하는 쪽에서 person, person.name을 넘기는데, 중복코드가 발생 let person = Person(age: 1, name: "jake") l..

공통 모델이 있을 때 리펙토링 방법 보통 공통 모델에서 특정 프로퍼티만 필요한 경우, 따로 DTO를 만들어서 convert 로직을 만드는데, protocol을 활용하면 간결하게 해결이 가능 ex) 공통 모델 CommonModel이 있고, 각 모델에서 필요한 모델도 각각 있어서 convert해서 쓰는 패턴 공통 모델이 CommonModel처럼 있는 경우 struct CommonModel { let age: Int var name: String let date: String let visited: Bool let imageData: Data var message: String } VC2, VC3에서 필요한 모델이 있어서 struct로 만들고 이걸 CommonModel에서 convert해서 쓰는 방식 stru..

객체 통째로 넘기기 객체에서 특정 값들을 가져와서 그 값들을 함수에 넘겨서 특정 일을 수행하는 것보다, 객체 통째로 파라미터로 넘길 것 이유1) 수정해야할 기획 의도가 생겼을 때, 객체 통째로 넘기게 되면 매개변수 목록은 수정하지 않아도 되는 편리함 이유2) 매개변수의 개수가 짧아져서 일반적으로는 함수 사용법의 이해가 올라감 이유3) 객체를 통째로 넘기지 않으면, 함수들끼리 같은 데이터를 사용하는 부분이 있을 것이고, 중복될 가능성이 커짐 (레코드를 통째로 넘기게 된다면 중복 로직을 방지할 수 있음) 객체 통째로 넘기기 예시) Room 이라는 인스턴스와 HeatingPlan 인스턴스가 존재 Room은 현재 방의 온도와 적절 온도 범위가 존재 HeatingPlan은 온도의 범위를 체크하는 일과 추후에 온도..

Assertion 추가하기 특정 조건이 참일 때만 동작하도록 하는 코드 영역이 있는데, 이러한 기능을 development 타겟에만 적용시켜서, 사전에 개발할 때 실수를 방지하도록 하는 기능 이러한 가정이 코드에 항상 명시적으로 기술되어 있지 않거나 이런 명시적인 것을 못보고 개발을 할 때 실수를 막기 위하여 assertion을 넣는 것 assertion 추가 시 주의사항 assertion 실패는 시스템의 다른 부분에 영향을 주지 않아야함 development 타겟에만 적용시켜 운영에서는 영향을 주지 않도록 해야함 assertion은 개발자가 실수를 할만한 곳이나 버그를 잡은 후에도 assertion을 넣으면 다른 개발자가 실수할 확률을 줄어주기 때문에 좋은 코드 Assertion 리펙토링하기 swift..

조건부 로직을 protocol로 바꾸기 이전 포스팅 글에서는 switch case 조건부 로직을 다형성으로 바꿨었는데, 상속을 사용하게되면 코드를 파악하기 어렵고 수정하기 어려운 반면에 protocol을 사용하면 이전 포스팅 글에서 알아본 대로 여러 이점이 존재 (아래 "Protocol 프로그래밍을 지향해야하는 이유"요약 참고) Protocol 프로그래밍을 지향해야하는 이유 *protocol = 자바의 Interface DIP (Dependency Inversion Principle): 소스코드 의존성이 구현체에 의존하지 않고 추상(protocol)에 의존하는 것 DIP 구체적인 개념은 이전 포스팅 글 참고 기능제공(=확장성) 확장성이라는 의미는 개발자가 코드를 작성할 때 매우 자연스럽게 사용이 가능 사..