작성 흐름

1. 클래스 정의
2. 메서드 작성
3. 테스트 코드 작성
4. 구현

1~4를 반복한다. 이렇게 하는 이유는, 행동을 기준으로 객체를 설계하고, 메서드를 기반으로 동작을 확인하기 위함이다. 만약 computed property가 있는 경우, 마찬가지로 테스트를 진행한다.

분리 시점

1. 내부에서 객체를 생성해서 사용하는 것을 지양한다.
   • 즉 의존성 주입 방식을 사용하여 설계하는 것을 생각해본다.

철칙

1. 필요없는 인터페이스는 만들지 않는다.
2. 테스트를 위한 함수도 만들지 않는다.
3. 명사형으로 끝나는 경우는 Computed Property를 사용한다.
4. 상위 모듈에서는 하위 모듈에게 일을 시키는 방향으로 코드를 구성한다. (호출 레벨이 동등해야 한다.)
5. 클래스 내부 프로퍼티는 기본이 private 이다.
   • IBOutlet, IBAction 역시 마찬가지이다.
6. 해당 기능이 클래스에 종속되지 않거나, 자주 사용될 경우 Util과 같은 곳으로 분리한다. (라이브러리 형식으로 사용)
7. 프로토콜 추상화는 method만 하는 것을 추천한다.
8. 함수하나를 짤 때도, 능동인지 수동인지 생각하면서 짠다.
9. 네이밍은 물흐르듯 읽을 수 있도록 해야 한다.
10. 자료구조를 적극 활용 한다. (Dictionary)
11. 특정 객체의 변경사항을 적용해야 한다고 할 때, 이걸 외부에서 적용해야 하는 것인지, 내부에서 처리해야 하는 것인지 고민한다.
    • 내부 속성 변경의 경우 내부에서 처리할 경우 능동적인 뷰로 만들 수 있다.
    • 이렇게 되면 할당 로직을 숨길 수 있다.
12. Computed Property의 경우 method아래에 두는게 나을 수도 있다.
13. 객체를 설계할 때, 단순 상속 말고, 동작에 따라 프로토콜로 나누는 것이 좋다.
    • 상속이외에 다른 특징(형용사)으로 Group화가 가능하다.
    • 해당 객체를 사용하는 쪽에서 역시 명시적으로 해당 객체 타입을 선언하지 않고 프로토콜을 타입으로 사용하여 interface로 사용하여 결합도를 낮출 수 있다.
14. 객체 생성은 Factory로 만들어 모듈화 한다.
    • 객체 개수도 여기서 관리하는 것이 좋을 수 있다.
15. extension에도 접근제어를 걸 수 있다.
16. Presenter란, 모델의 값을 뷰로 보내기전에 이를 처리하는 로직을 의미한다.
    • 이를 객체 형태로 만들어서 관리할 수도 있을 것이다.
    • 하지만 모듈화하더라도 뷰와 관련된 로직이기 때문에 테스트가 불가하다.
17. 이미지는 URL만 가지고 있다가, 보이는 시점에 그린다.
18. 특정 로직 자체를 활용하는 방법 자체가 달라질 수 있는 경우라면 UseCase라는 객체를 만들어 사용하는 것이 모듈화 측면에서 좋다.
19. String으로 프로퍼티를 가지고 있는 경우는 지양한다. 만약 값의 범위가 명확하게 정해져 있다면 enum과 같은 방법을 활용한다.

Tip

• extension을 잘 활용하면 코드의 길이가 줄어들 수 있다. 중복 코드 제거
  • NSObject extension을 활용해서

    class var className: String {
      String(describing: self)
    }
    

  • 이렇게 적어두면 모든 클래스에서 사용이 가능하다.
• 기본타입을 사용하는 것을 지양하고, 통제, 제한 하는 방식으로 구현한다.