2017.12.04

TIL

• 좌표계산기 리팩토링
  • InputChecker에서 Mypoint의 유효여부를 체크하는 부분 책임 나눔
    • InputChecker에 있던 거대한 함수 두개를 잘게 쪼개서 private으로 선언
    • InputChecker에 있던 MyPoint의 유효여부 검사의 책임을 MyPoint로 넘김
  • 도형의 꼭짓점이 서로 같은지 체크하는 부분 개선
  • 그 외 피드백 개선
    • inValidShape같은 이중부정의 뜻으로 함수를 쓰지말고 “isValid, true일때 정상, false일때 에러처리”와 같이 직관적으로 수정
    • main 파일에서 가독성을 위해서 인스턴스나 변수를 맨 위에 다 선언하지 말고 사용하는 부분 위에 선언하기
• 빅너드랜치 - 에러처리부분 읽기
• 자기가 하는 일의 양을 가늠하고 아는게 중요함!

2017.12.05

TODO

• JSON parser 시작
  • step1 개요짜기
  • 여러 타입을 담는 어레이 공부
  • 정규표현식 공부 (step3부터하기…)

TIL

• trimmingCharacter로 공백자르기
• 반복문-조건문에서 continue를 쓰자. (반복문안의 조건문의 밖- 특히 아래에 코드가 있으면 조건문을 빠져나가더라도 반복문에 코드가 실행된다는걸 명심!)
• guard let 옵셔널바인딩
• 예외가 나거나 내가 A상황을 가정하고 A를 입력해서 테스트하는데 맞지 않는 결과가 나오면 무작정 이게 안되네ㅠㅠ? 라고만 생각할게아니라 왜 안돼는지 여러 변수를 따져봐야하고 살펴봐야함. 오늘 코드에 문제가 없는 상황에서, 내가 입력한 값이 예상한대로 변환이 안돼서 디버깅을 하다가, 아무리 찾아봐도 모르겠었는데 알고보니 복사-붙여넣기로 readLine()에 값을 넣으면서 예상치 못한 값이 들어갔던것이 문제였다. 이처럼 내가 생각치못한 변수가 있을 수 있으니 코드를 뜯어보는것 이외의 여러 상황에도 가정을 하고 다양하게 디버깅을 하는게 중요하다!

2017.12.06

TIL

• trimmingCharacter공부
• Any / AnyObject를 담는 Array 공부
• 실용주의사고와 학습 읽기
• step1 피드백 처리 / 개선부분 개선

2017.12.07

TIL

• step1 피드백 처리
• JSON step2단계로 가기
• 딕셔너리 복습하기
• 실용주의 사고와 학습 읽기

2017.12.08

TIL

• step2 PR
  • 배열 안에 객체 여러개 있는 경우를 검사하는게 남음
    • string나누는거처럼 {} 기준으로 해야하는지 아니면 {}객체모양으로 있는건 다 객체로 간주 counting을 할 수 있도록 짜야 하는지…(좌표계산기의 myPoint처럼)
  • PR 보내고 피드백 처리하기
• 손에 잡히는 정규표현식을 읽으면서 정규표현식이 무엇인지 알아봄!
• step2를 하다가, 1단계부터 잘못 짠 부분(AnyType의 Array를 만들었어야했는데 그냥 카운팅만 함)이 있어서 전부 다 지우고 다시 시작했다!
• if문이 많아지면 코드이 복잡도가 높아짐. if문이 함수 내에 있으면 항상 의심해보기!

좌표계산기 리뷰

• 미션 진행 기간 : 2017.11.16 ~ 2017.12.04
• 좌표값을 입력받으면 4사분면 위에 입력받은 좌표값을 출력하고, 좌표값에 의해 표시된 도형의 길이나 넓이를 계산하여 출력하는 프로그램
• 좌표계산기 미션 github 저장소 바로가기

배운 것

프로토콜을 사용했다. (+ 프로토콜 컴포지션)

이론만 들었을때는 어려운 개념이라고 생각했는데 사용하고 보니 오히려 프로토콜로 인해 더 쉽게 구현되는게 많았다.
추상화 : 각기 다른 객체를 한 메서드에서 사용해야할때 내부에서 하나의 이름, 하나의 타입으로 각각 다른 객체를 파라미터로 받을 수 있다는게 가장 유용했다. 만약 이렇게 하나의 프로토콜로 묶지 않았으면 각 객체는 하나의 메서드의 파라미터로 들어가는 조건을 충족하기 위해서 필요 이상으로 과도하게 많은 프로퍼티를 가지도록 설계하거나 다양한 객체를 받아서 처리해야하는 부분이 과도하게 복잡해졌을것이다.
그리고 프로토콜은 각 객체가 반드시 구현해야하는 메서드들을 정의해놓는데 이게 어떻게 보면 각 객체는 꼭 이 역할을 해야한다는 책임 분담과 같은 것이라 객체의 역할분담에도 유용히 쓰였던 것 같다.
예를들어 나는 각 도형이 성립되는 조건을 검사하는 책임을 어디에 두어야 할지 감이 잘 안왔는데 ‘도형’으로 추상화를 하고 모든 도형의 공통되는 부분인 유효성 체크 메서드를 준수하도록 설계하니까 input이나 factory객체의 책임이 과도하게 늘어나는걸 제한 할 수 있었던 것 같다.
“점 - 직선 - 삼각형 - 사각형” 순서로 미션이 확장되었는데 직선 구현 단계에서 프로토콜을 구현하니까 오히려 더 어려운 미션이었던 삼각형과 사각형을 추가는 구현 시간이 훨씬 더 짧았다.

접근제어자를 사용하는데 익숙해졌다.

private 함수를 쓰는 것이 처음엔 생각하기 까다롭다고 생각했었는데, 이제는 당연히 내부에서만 쓰는 함수와 아닌 것을 구분해서 접근제어자를 쓰려고 한다.
main 파일도 이런 식으로 접근하면 지금보다 줄어들 것 같다.

객체의 책임 분리가 덜 어색해졌다.

처음에는 “객체의 책임”이라는 단어 자체가 와닿지가 않아서 책임을 분리하는게 굉장히 어색했다.
그래서 설계가 나중에 가면 뒤틀어지고 대규모 공사를 하는…그런 경우가 있었는데 지금은 기능 하나, 객체 하나가 추가될 때마다 책임과 역할, 그리고 협력하는 객체는 무엇인지 자연스럽게 떠올리게 됐다.

객체의 생성과 소멸

• 객체나 변수를 미리 생성해놓지 말고 사용하는 scope 안에서 생성되고 다른 scope에서 사용될 일이 없으면 해당 scope안에서 소멸되도록 사용하는 습관을 길러야 한다.
  예를들어 main파일에서 습관적으로 상위에 모든 인스턴스를 다 선언해놓고 아래쪽에서 인스턴스.메서드해서 사용하는데 적어도 사용하는 시점에 인스턴스를 만드는 습관을 들이자. (심지어 do-catch문 안에서도 인스턴스를 생성할 수 있다. 필요하면 그렇게 하자.)
• 단지 객체의 프로퍼티값이 필요할 뿐이라고해서 객체를 또 생성할 필요는 없다. 객체는 필요할 때만 생성하고 프로퍼티값을 객체 생성 없이 가져올 방법이 있는지 고민하고 객체를 새로 또 생성하는 방법은 최대한 배제하자.

에러처리

• do-try-catch를 한꺼번에 다 쓰지 말고 하나의 에러케이스enum에 하나의 do-try-catch가 있어야 한다.
• 에러체크를 할때는 습관적으로 if-else를 사용하기보다는 만약 에러처리하고 해당 메서드를 끝내는 로직이 자연스럽다면 guard를 사용하는 습관을 들이는게 더 좋을 것 같다. guard 더 자연스럽다.
• 에러체크를 하는 함수 이름을 직관적으로 짓자.
  나는 invalid- 로 이름을 정해서 true일때 에러를 throw하고 false일때가 정상케이스일 경우로 짰는데(if !invalid() {return value} 이런식으로…) 나 말고 다른사람은 이해하기 힘들것이라는 리뷰를 받았다. 오히려 직관적으로 isValid()- 처럼 이름을 짓고 로직을 반대로 하니까 guard문으로 단순화 하는 것도 쉽고 더 읽기 쉬운 코드가 됐다.

부족했던 것

• 좌표계산기 로직에 맞는진 모르겠지만 상속을 적용했다면 어땠을까 하는 생각이 든다.(‘점 > 직선 > 삼각형 > 사각형’의 흐름이기때문에. 점이 모든 도형을 포괄하는 가장 큰 개념이다.)
• Set의 사용 : 좌표값이 서로 같은 좌표값은 없는지 체크해야했었는데 Set 타입으로 좌표를 담으면 쉽게 처리가 됐을텐데 하는 아쉬움이 있다.
• 필요한 클래스나 메서드의 재정의 : Equatable프로토콜을 오버라이드해서 사용했지만 오버라이드를 하는 컨셉이 생소해서 간단한 코드였는데도 불구하고 구현도, 사용도 어려웠다. 그리고 sorting하는 기능이 필요해서 Comparable프로토콜을 오버라이드할 필요가 있었는데 결국 사용하지 못하고 미션이 끝났다.
• main.swift 파일이 깔끔하지 못한 것. 지금은 반복문 내에서 에러처리를 하는 식으로 되어있는데 메서드로라도 프로그램을 실행하는 로직을 분리했으면 더 깔끔했을 것 같다.
• 유닛테스트를 제대로 하지 못한 것. 이상적이게는 함수 하나 추가할때마다 테스트코드를 추가해야하는데 문제를 풀어가다보면 그 흐름을 끊고 테스트코드를 짜기 어렵다.
• 커밋단위를 잘게 쪼개지 못한 것. 신경써서 하긴 했지만 기능 추가하다보면 계속 이어서 하게됐다…
• 커밋메시지를 길게 쓴것 같다. 명확하게 쓰는게 좋다고 해서 썼는데 너무 구체적으로 쓴건 아닌가 싶다.

앞으로 할 것

• 객체는 필요한 곳에서 선언하고 과도하게 생성하지 않기
• main.swift 내의 로직을 단순화해보기
• 에러처리 시 습관적으로 if-else만 쓰지 않고guard를 사용하기
• 에러처리 시 do-try-catch를 한 에러타입 당 하나의 구문을 사용하기
• 객체의 협력을 건너뛰거나 거슬러올라가지 않기 : 똑같은 데이터라도 현재 협력하고 있는 객체에게 그 데이터를 요청해야지 협력하고 있지 않은 객체에게서 데이터를 받아는 형태가 되면 의존성이 높아짐
• 구조체나 클래스 이름은 -ing 형태보다는 의인화(마치 사람처럼) Manager, Checker, Player 형태로 네이밍하는게 보편적임
• computed property를 사용했던 것 처럼 프로퍼티가 특정한 로직으로 계산되어야 할때는 get메서드를 만들지 말고 getter 프로퍼티를 사용하기
• 커밋단위를 작게 나눠서 커밋하기 : 하나의 기능이 추가될 때마다 확인하고 커밋하기!
• 유닛테스트 습관화하기

이번 주에 배운 / 느낀 것

• 거의 좌표계산기 미션에만 매달렸던 한 주 였다…!

• 반복문…
  • 반복문 안의 조건문을 쓸때 착각해서 내가 생각했던 것보다 더 반복이 된다던지, 덜 된다던지 하는 실수가 잦았다. 예를들면 Array에 값을 추가해야 하는데 자꾸만 마지막 값만 들어가는 문제가 있어서 디버깅을 이방법 저방법으로 했는데 알고보니 for문 scope밖에서 .append를 했던 문제였다. 반복해서 특정 조건에 따라서 처리해야하는 로직에서는 scope에 주의하고 조건문에 걸리지 않는 경우에 반복문 내에 있는 모든 코드는 반복된다는 사실을 꼭꼭 기억해야겠다!
  • 좌표계산기 미션의 main파일에 while문 추가 : while문을 추가하고 종료조건을 새로 추가하면서, 원래 에러처리도 하던 로직이라서 좀 까다로웠는데 앞으로 미션 만들면서 프로그램 실행과 종료에는 종료조건을 추가해서 연습은 계속해야겠다.
• 프로토콜
  • MyPoint처럼 만든 객체를 Equatable 프로토콜을 준수하게 만들어서 필요한대로 사용했다. 프로토콜같이 처음에 이해가 모호하게 됐던 개념들은 사용하면서 점점 더 익숙해지는것같다.
  • 프로토콜 컴포지션 : 원래 하나의 프토콜로 커버할 수 있던 객체들이 기능이 점점 추가되면서, 하나의 프로토콜로 완벽히 추상화가 어려워졌다. 이런경우, 아예 공통되는 기능만으로 프로토콜을 하나 더 생성하고 그 기능이 필요한 객체만 새로운 프로토콜을 준수하게 나눠서 구현한다.
    • ex)ResultByShape 프로토콜 - 출력되는 결과값의 유무가 각 도형마다 달라서 MyShape프로토콜이 결과 출력과 관련된 함수를 갖고있는게 적절치 않았음. 결과 출력을 하는 함수만 따로 ResultByShape프로토콜에 새로 정의하고 결과를 출력할 필요가 있는 도형객체만 준수하게 구현.
      drawPoint()함수의 파라미터는 프로토콜 컴포지션(MyShape & ResultByShape)를 받는 것으로 수정.
• 에러핸들링
  • do-catch문을 에러타입에 따라서 나누는 것을 사용해보면서 좀더 익숙해질 수 있었다.
  • 에러케이스 enum을 Error프로토콜을 준수하도록 설계해서 같은 타입의 에러를 또 에러 케이스에 따라 구분하기 위해서 중복되게 작성했던 catch문을 case에 따라서 수를 줄일 수 있었다.
• 절대값을 구하는 프로퍼티 magnitude
• 유닛테스트 활용
• 연산형 프로퍼티
• static활용

프로토콜

프로토콜은 타입이 만족시킬 인터페이스를 정의할 때 필요하다. 타입이 프로토콜을 만족시킬때 프로토콜을 준수한다고 말한다.

프로토콜은 타입 자체로 사용될 수 있어서 프로토콜 타입을 가지는 변수나 함수 인수 리턴값을 사용할 수 있다.

프로토콜이 필요할때

func printTable(_ data: [[String]], withColumnLabels columnLabels: String...) {
    var firstRow = "|"
    var columnWidths = [Int]()

  ...

• 이 함수는 행과 열이 몇 개인지 알아야 한다. 인수를 두 개 받아서 반복문으로 table을 출력하는 함수이다. 하지만 프로토콜을 이용해서 TableData를 정의한 프로토콜만 받아도 작동되게 설계할 수 있다.

프로토콜 정의

...
protocol TableDataSource {
  var numberOfRows: Int {get}
  var numberOfColumns: Int {get}

  func label(forColumn column: Int) -> String
  func itemFor(row: Int, column: Int) -> String
}

• get 문법은 프로퍼티가 읽기용이라는뜻이다.
• 프로토콜은 타입이 이런 프로퍼티와 메서드만큼은 가져야한다는 최소 요건을 정의한다. TableDataSource 를 준수하는 타입들은 numberOfRows, numberOfColumns프로퍼티, label(), itemFor()메서드를 반드시 구현해야한다.

프로토콜 사용

정의한 프로토콜 TableDataSourse를 준수하는 Department 구조체를 만든다. 위에서 언급했듯이 프로토콜을 추상클래스처럼 사용할 수 있어서, 이 구조체는 TableDataSource타입이 되고 TableDataSourse타입처럼 사용될 수 있다. (ex TableDataSource를 인자로 받는 함수에 Department가 들어갈 수 있음)

struct Person {
    let name: String
    let age: Int
    let yearOfExperience: Int
}

struct Department: TableDataSource { //TableDataSource 프로토콜을 준수함
    let name: String
    var people = [Person]()

    init (name: String) {
        self.name = name
    }

    mutating func add (_ person: Person) {
        people.append(person)
    }

  // 프로토콜에 정의된 numberOfRows와 numberOfColumns는 {get}방식 읽기용 프로퍼티
    var numberOfRows: Int {
        return people.count
    } //var numberOfRows: Int = people.count같음 (이렇게는 사용못함!)

    var numberOfColumns: Int {
        return 3
    }

  // 사용할때 column순서만 정해주면 매칭되는 케이스에서의 문자열을 리턴
    func label(forColumn column: Int) -> String {
        switch column {
        case 0: return "Employee Name"
        case 1: return "Age"
        case 2: return "Years of Experience"
        default: fatalError("Invalid column")
        }
    }

  // Department의 프로퍼티인 Person리스트에서의 person정보를 조회. 행/열 번호만 정해주면 해당 person객체의 속성을 반환  
    func itemFor(row: Int, column: Int) -> String {
        let person = people[row]
        switch column {
        case 0: return person.name
        case 1: return String(person.age)
        case 2: return String(person.yearOfExperience)
        default: fatalError("Invalid column!")
        }
    }
}

extension에 프로토콜적용

extension은 이미 존재하는 클래스나 구조체, 열거형 등의 객체에 새로운 기능을 추가하여 확장할 수 있는 키워드이다.
extension은 라이브러리나 프레임워크에 포함되어 직접 접근할 수 없는 객체라도 확장 구문을 이용하면 제약 없이 새로운 기능을 추가할 수 있다. 또한 extension에 프로토콜을 적용할 수 있다.
프로토콜과 관련된 확장의 특징 중 하나는 기존 객체를 수정하지 않고도 프로토콜을 구현할 수 있다는 것이다.

<String과 Dictionary의 확장 구문에 프로토콜 구현>

protocol ConvertTarget{

}

extension String: ConvertTarget {

}
extension Dictionary: ConvertTarget {

}
// String과 Dictionary는 프로토콜로 인해 ConvertTarget타입으로 한꺼번에 사용 할 수 있게 되었다.

열거형

리스트 형태로 정의된 여러 케이스로 인스턴스를 만들 수 있는 방법

enum은 한번 저장해(메모리에 올려)놓고 값을 변경해서 쓰지 않는 상수개념이기때문에 static변수처럼 쓰여 인스턴스 프로퍼티로 사용하면 컴파일에러가 난다! (스트럭트이름.enum타입) 으로 사용

열거형의 타입 추론

변수의 타입이 열거형이라는 것만 알고있으면 새 값을 대입할 때 타입을 생략할 수 있다.

...
var alignment = TextAlignment.left
alignment = .right

처음에 alignment변수를 만들때는 열거형의 타입과 값을 지정해야했지만, 그 다음 행부터는 타입을 생략하고 그 타입의 다른 값으로 지정할 수 있다. (값을 함수에 전달할때나 비교할 때도 열거형 생략 가능)

조건문을 switch로 쓰기

enum TextAlignment {
    case Left
    case Right
    case Center
    case Justify
}

alignment = .Right //타입 추론

if alignment == .Right { //비교할때도 타입추론 가능
    print("We should right-align the text!")
}

//열거형의 값을 if문에서 비교할 경우 보통 switch구문을 사용함
switch alignment {
case .Left: print("Left Aligned")
case .Right: print("Right Aligned")
case .Center: print("Center Aligned")
case .Justify: print("Justified")
}

• switch - case를 쓸때 열거형에서는 default 케이스를 쓰지 않는 것이 좋다.(컴파일러가 이미 모든 가능한 값을 알고 있기때문에)

메서드

스위프트의 메서드는 열거형과도 연동된다.

// playground(전구켜기)

enum Lightbulb {
    case on
    case off

    func surfaceTemperature(forAmbientTemp ambient: Double)-> Double { //Lightbulb의 메서드
        switch self {
        case .on:
            return ambient + 150.0
        case .off:
            return ambient
        }   
    }   
}

var bulb = Lightbulb.on
let ambientTemperature = 100.0
let bulbOnTemperature = bulb.surfaceTemperature(forAmbientTemp: ambientTemperature)
print(bulbOnTemperature) // 250.0

surfaceTemperature함수는 enum타입의 Lightbulb 내부에 선언되어있으며, 전구가 켜져서 전구 표면의 온도가 올라가면 주변의 온도도 올라가는 것을 표현한 메서드이다.

• self : self는 Lightbulb타입의 암묵적인 인수. 스위프트의 메서드는 예외없이 self인수를 가지는데, 이 self는 해당 메서드가 호출되는 인스턴스에 엑세스하는데 사용된다. 여기서는 Lightbulb의 인스턴스에 엑세스하는데 사용된다.

// playground(전구 켜고끄기)

enum Lightbulb {
    case on
    case off

...


// toggle()함수를 호출하면 전구가 on상태일때 off하고, off상태일때는 on.

   mutating func toggle() {
        switch self {
        case .on:
            self = .off
        case .off:
            self = .on
        }
    }
}

var bulb = Lightbulb.on
let ambientTemperature = 100.0
var bulbTemperature = bulb.surfaceTemperature(forAmbientTemp: ambientTemperature)
print(bulbTemperature)


bulb.toggle() // bulb는 .on상태였으니까 여기서 toggle을 호출해서 off상태로 바꿈
bulbTemperature = bulb.surfaceTemperature(forAmbientTemp: ambientTemperature)
print("after toggle: \(bulbTemperature)") // after toggle: 100.0

연동되는 값

enum ShapeDimensions {
    case square(side: Double)
    case rectangle(width: Double, height: Double)  

    func area() -> Double {
        switch self {
        case let .square(side: s):
            return s * s
        case let .rectangle(width: w, height: h):
            return w * h
        }
    }
}

// ShapeDimensions의 연동값을 만들려면 해당 케이스와 그에 따른 적절한 연동값을 지정해야한다.
var squareShape = ShapeDimensions.square(side: 10.0) // 한변 길이 10.0인 정사각형 생성
var squareShape2 = ShapeDimensions.square(side: 5.0) // 한변 길이 5.0인 정사각형 생성
print(squareShape.area()) // 100.0
print(squareShape2.area()) // 25.0
var rectangleShape = ShapeDimensions.rectangle(width: 5.0, height: 10.0) // 직사각형 생성
print(rectangleShape.area()) // 50.0

• ShapeDimensions에서
  • 정사각형의 연동값은 한 변의 길이
  • 직사각형의 연동값은 그 너비와 높이 - 튜플로 width와 height
• let: switch의 케이스들의 self의 연동값을 새 변수에 바인딩하기위해 사용. 연동값을 주고 그에 따라서 ShapeDimensions타입의 케이스를 만들어내는데, 주어진 연동값이 변동됐을때도 딱 그때 호출된 케이스에 제대로 바인딩된 값만 주려고 let으로 상수 바인딩을 시키는것! let이 없으면 컴파일에러가 나는데, 만약 var squareShape = ShapeDimensions.square(side: 10.0)나 var squareShape2 = ShapeDimensions.square(side: 5.0)처럼 연동값을 다르게 해서 호출했을때 바인딩을 안해주면 두 번 다 하나의 같은 연동값이 적용될수도 있다. 그래서 컴파일러가 막아놓은것 같음. (let은 어쨌든 연동값으로 들어온 s, w, h를 바인딩하기위함임. 내일 설명을 듣고 더 매끄럽게 정리해야겠다.) enum에 연관값이 있을때 연관값이 무엇인지도 알아야하고 그것을 사용하기 위해서는 한번 더 비교해서 값을 꺼낸다는 개념