스위프트에서 단식 디자인을 변형시킬 수 있는 개인 고찰

며칠 전 다음 스위프트에 대한 질문을 트위터에 올려 예상치 못한 답변을 많이 받았고, 제 생각을 간단히 정리해봤습니다.
Q. 어느 반의 디자인이 더 좋다고 생각하는지 이유를 대답해 보세요.
(왜 단식을 한쪽에 놓고 사용 전제에서 두 가지 선택이 있는가)

// typealias Izon = IzonProtocol とする

class Shared1 {
    static let shared = Shared1()
    var izon: Izon!
    private init() {}
    static func setup(izon: Izon) {
        shared.izon = izon
    }
}
class Shared2 {
    static var shared: Shared2!
    var izon: Izon
    private init(izon: Izon) {
        self.izon = izon
    }
    static func setup(izon: Izon) {
        shared = Shared2.init(izon: izon)
    }
}

내 복잡한 대답 TLDR

해설

본 문제의 코드는 액세스 수식자를 사용한 사용이 난잡하고 안전하지 않은 임플리시티 Unwrapped Optional(IUO), Izon 촌스러움 등 익살스러운 부분이 많은데 해석 방법은 여러 가지 측면에 걸쳐 문제를 간소화하는 상황을 고려해 봤다.

코드 간소화

우선 전선을 안전쪽으로 옮기기 위해let,private(set)와 보통Optional을 사용하고 눈에 익은 모양으로 살짝 쓰세요.

class Shared1 {
    static let shared = Shared1()
    private(set) var izon: Izon?
    private init() {}
    static func setup(izon: Izon) {
        shared.izon = izon
    }
}

class Shared2 {
    private(set) static var shared: Shared2?
    let izon: Izon
    private init(izon: Izon) {
        self.izon = izon
    }
    static func setup(izon: Izon) {
        shared = Shared2.init(izon: izon)
    }
}

추출류 핵심 부분

이어 static 부분을 extension 범위로 미루고 학급의 핵심 부분인'구성원 변수'와'초기화기'에 착안했다.

// クラスのコア部分（メンバ変数とイニシャライザ）

class Shared1 {
    private(set) var izon: Izon?
    private init() {}
}

class Shared2 {
    let izon: Izon
    private init(izon: Izon) {
        self.izon = izon
    }
}

// クラスのその他 (static) の実装 (NOTE: extension に移動できる)

extension Shared1 {
    static let shared = Shared1()
    static func setup(izon: Izon) {
        shared.izon = izon
    }
}

extension Shared2 {
    private(set) static var shared: Shared2?
    static func setup(izon: Izon) {
        shared = Shared2.init(izon: izon)
    }
}

면class Shared1과class Shared2읽기 쉬워진다.
나는 이때 이미 평소에 어떤 코드를 즐겨 쓰는지 어렴풋이 볼 수 있을 것이라고 생각한다.
네, class 안에 쓰지 않아도 돼요varclass Shared2는 익숙해요.
이 이야기를 쉽게 이해할 수 있도록 izon 외에도 많은 파라미터를 주어보자.

class Shared1 {
    private(set) var izon: Izon?
    private(set) var izon2: Izon2?
    private(set) var izon3: Izon3?
    ...
    private init() {}
}

class Shared2 {
    let izon: Izon
    let izon2: Izon2
    let izon3: Izon3
    ...
    private init(izon: Izon, izon2: Izon2, izon3: Izon3, ...) {
        self.izon = izon
        self.izon2 = izon2
        self.izon3 = izon3
        ...
    }
}

// NOTE:
// static func setup(izon: Izon, izon2: Izon2, izon3: Izon3, ...) になる

그렇구나class Shared2흔한 문법이지만 class Shared1대량의 var+Optional멤버 변수가 생길 거라고 상상할 수 있는 나쁜 모델이다.
여기서 왜 위class Shared1의 유형 디자인이 좋지 않은지 생각해 봅시다.
대수 데이터 형식의 관점에서 보면

class Shared1의'다수의 Optional(직화)의struct(직적)형'은

이다.

class Shared2의 단순struct(직적)형

이에 비해 필요 없는 상태를 포함하는 패턴을 포함해 복잡하게 만들었다고 할 수 있다.class Shared1 초기화init 실시 중 재료를 줄이는 부분은 그 계산서가 가변 구성원 변수인 Optional로 나타난다고 할 수 있다.
물론 이 몇 가지 Optional 문제와 관련해서도 아래처럼 한 곳에 집중해 회피할 수 있다.

class Shared1 {
    private(set) var izons: (Izon, Izon2, Izon3, ...)?

    private init() {}
}

그러나 이것class Shared2과 비교하면 익숙하지 않고 고통스러운 묘사라고 할 수 밖에 없다.
원인은 뚜렷하다shared의 가변성var+Optional는static측이 아니라 구성원 변수측에 위탁되었다.
따라서 static func setup의 izon 매개 변수 수량의 확장으로 인해 class Shared1 구성원 변수가 유연하게 확장되지 못하는 단점이 있다.

조망 extension(static 부분)

그럼 아까 얘기로 돌아가서 extension에 쫓기는 static 실현에 다시 한 번 주목해 봅시다.

// クラスのその他 (static) の実装

extension Shared1 {
    static let shared = Shared1()
    static func setup(izon: Izon) {
        shared.izon = izon
    }
}

extension Shared2 {
    private(set) static var shared: Shared2?
    static func setup(izon: Izon) {
        shared = Shared2.init(izon: izon)
    }
}

이런 상황에서 어떤 실현 방식이 더 좋아요?
개인적으로도 이 경우Shared2도 분명히 shared옵티올이라 미리 불러야 한다static func setup며 코드 분위기에서 전달된 것이라 좋아했다.Shared1의 경우 Optional의 정보도 구성원 변수 옆에 숨겨져 있고 식별하기 어려운 단점이 존재한다)
그러나 위에서 말한 바와 같이 static func setup회가 (N≠1)회로 불리는 상황에서 "shared 자체의 교체", "내용만 교체izon", "설정치 미설정(IUO의 경우 붕괴)"등의 동작의 차이 등이 실천에 큰 악영향을 미칠 가능성도 있다.디버깅의 단순성을 감안하더라도 어느 것이 좋은지 단언할 수 있는 것은 아니다. 나는 대답이 그리 간단하지 않다고 생각한다.

총결산

그래서 저는 개인적으로 넘어져도 단식이 되는 문제가 지옥이라면 적어도 학급 핵심 부분의 디자인은 예뻐질 수 있다고 추천합니다Shared2.
(가장 가까운 대답은)
그러나 이 추천은 도대체 static func setup 프로그램이 시작된 후의 인력 호출 보증일 뿐이고 가설(N≠1) 호출 위험은 거의 무시할 수 있다.