TIL_20180423 ~ 20180430

2018.04.30

• 4월 회고
• 카드게임 CardDeckDelegate 싱글톤구현

  class CardGameDelegate: CardGameManageable {
  
    static let defaultStackRange: CountableClosedRange = 1...7
    static let defaultStackNumber: Int = 7
  
    private static var sharedCardDeck = CardGameDelegate()
  
    private init() {
        cardDeck.shuffle()
        var stacks = [CardStack]()
        for numberOfCard in CardGameDelegate.defaultStackRange {
            let oneStack = cardDeck.makeStack(numberOf: numberOfCard)
            oneStack.sortDefaultStack()
            stacks.append(oneStack)
        }
        self.cardStacks = stacks
    }
  
    class func shared() -> CardGameDelegate {
        return sharedCardDeck
    }
    // 앱 내 어떤 클래스에서 이 메소드를 호출하더라도 이미 초기화된 sharedCardDeck만 리턴됨
    // 이때 초기화나 객체생성은 자기 자신 (CardGameDelegate)만 스스로 할 수 있도록 보호되어있음
  

4월 회고

Good

• 자판기완성!
• 카드게임부터 깃헙 이슈관리를 사용하기 시작했는데 적응됐다. 큰 요구사항도 단계별로 쪼개고 하나의 이슈로 관리하니까 수정사항 관리와 피드백관리가 편해짐.
• 커밋메시지쓰는 방법을 통일시키고 이슈번호와 함께 관리
  • 커밋메시지는 항상 타이틀: 간략 내용 형식으로 쓰고 만약 내용이 길어지면 아래 줄로 내려서 내용을 쓴다
• 뷰 - 뷰모델의 관계와 만드는 방법 이해함
  • 책임과 역할이 분명해진다: 그냥 단순 MVC보다 V-VM 관계를 만드니 더 책임과 관계의 경계가 명확해지는것같았다. 뷰모델에 있는 로직대로 바뀐 내용을 뷰는 그리기만 하면 된다.
  • 테스트가 가능해진다: 이렇게 되면 뷰모델을 테스트함으로써 뷰를 매번 그려가면서 결과화면을 보거나, 프린트로 그려지는 값을 찍어보는 1차원적인 방법으로 디버깅을 하지 않아도된다.
  • 또한 뷰모델을 만들면서 프로토콜에 의존하는 방법 (SOLID법칙에서 L - 다형성)을 이해하게됐다.
  • 모델을 확장 가능하게 만든다: 뷰와 뷰모델관계에서는 뷰가 뷰모델을 구현한 클래스를 속성으로 갖게되는데, 이때 뷰가 모델을 직접 가지는게 아니라 해당 모델클래스가 상속(구현)하고있는 프로토콜 타입을 가져야 한다.
  • 이렇게 모델클래스를 추상화한 프로토콜이 따로 있고, 어떤 클래스가 모델로 오더라도 확장에 열려있는 구조를 사용하는 것이 좋다. 이렇게 되면 뷰가 직접 모델을 가지는것이 아니라 프로토콜에 의존하는 약한 의존성을 갖게된다.

Bad

• 주말이나 수요일같은 여유시간에 공부를 많이 못했다. 쉴땐 쉰다는 핑계로..
• 근데 난 하나의 배경지식이라도 중요한 비전공자니께…
• 일단은 도움이 안되도 들어놓고 봐놓으면 언젠간 정말 도움이 되는것 같다.
• 처음 듣거나 볼때는 아예 모르겠는 말이 많은데, 한번 처음 볼 때 무슨 말인지 모르더라도 일단 봐두면 나중에 적어도 생소하지는 않으니, 처음보다는 편한 부분이 있었다.
• 항상 귀를 열고 눈을 열자!