인터페이스, 즉 스위프트의 Protocol의 중요성.
책임-주도 설계(Responsibility-Driven Design)
설계를 해서 internal 메소드로 활용될, 즉 협력에 필요한 메소드들을 추린다. 가능한 한 잘 추려서 해당 internal 메소드를 선언한 protocol 타입을 만든다. 구체적인 클래스들은 해당 프로토콜 타입을 채택함으로써 커플링을 줄인다. 이렇게 설계 -> 프로토콜 구현 -> 클래스를 구현을 차례대로 한다면 이후에 해당 프로토콜의 역할을 채택한 필요한 다른 클래스로 교체해야 하는 상황이 올 때 코드를 유지보수 하기 쉬워진다.
Design Pattern
- Delegate Pattern
- => 보통 하위 객체(
상위 객체가 가지고 있는 멤버 객체)가 상위 객체(하위 객체를 프로퍼티로 가지고 있는 객체)를 알아야 할 때 자주 쓰는 패턴입니다. Delegate 패턴은 하위 객체가 상위 객체를 알아야 하는 경우에만 써야 하는 패턴이고, Delegate 패턴 자체가 커플링을 늘리는 행위라 쓰지 않아도 될 경우에 쓰는 것은 옳지 않습니다. 가령 자신의 상위 객체인 ViewController를 weak var 로 가지고 있는 경우는 좋지 않은 케이스 입니다. ViewController를 weak로 가지고 있는 것 대신 다른 방법은 없는지 고민해야 합니다. 예전에 관련해서 받았던 코멘트.
NOTE: 상위 객체와 하위 객체의 관계
class 상위_객체 {
let a = 하위_객체()
}
class 하위_객체 {
}- Composite pattern
- OOP 에서 컴포지트(Composite)패턴은 하나 이상의 유사한 객체를 구성으로 설계된 객체로 모두 유사한 기능을 나타낸다.
- 간단히 말해 한 화면안에 여러 VC가 있는 것(RIBS 아키텍처로 얘기하면 하나의 RIB안에 여러 RIB이 있는 것)을 Composite Pattern이라고 말할 수 있다.
NOTE: Composite Pattern UML
TDD(Test-Driven Development)
- TDD는 테스트 가능한 구조를 만들수 있는 가장 강력한 프랙티스이다.
- TDD를 하려면 의존성 역전 원칙(Dependency Inversion Principle) 사용은 필수이다.
- TDD를 하려면 가짜 객체가 필요한 경우가 있다.
- Mock, Stub, Spy, Fake, Dummy
- 역할, 책임, 협력에 집중하고 객체지향의 원칙을 적용하려는 깊이 있는 고민과 노력을 통해서만 테스트-주도 개발의 혜택을 누릴 수 있다.