テスト駆動開発の第一部をSwiftで写経してみた

これはなに?

  • 社内でテスト駆動開発(Test Driven Development = TDD)の勉強会を行った
  • これはそのときの発表資料です
  • 自分はiOSエンジニアなのでSwiftでやってみた
  • 参加した同僚達は Go, Ruby, Dart, Elm などで写経している
  • 第一部を写経する前に「付録C 訳者解説:テスト駆動開発の現在」を先に読むのをオススメする
  • 社内勉強会では、付録Cの概要をみんなで共有してから第一部の写経に進んだ

Swiftで写経

  • Swiftで出来るだけ書籍通りに書いてみた
  • 出来るだけ同じように書かないと写経できなくなるので、Swiftでは非推奨な書き方もある
    • そこは後述で補足する
  • コミットは書籍でテストを走らせたタイミングや、ある程度意味のありそうな塊できった
    • 電子書籍だからページ番号がフォントサイズで変わるので、どの章のコミットかわかるようにメッセージの先頭に「第n章」とつけた
  • TDDの説明ではなく、JavaとSwiftの言語仕様の違いが際立ってしまった
    • 写経することがTDDを理解することの近道なので写経がまだの人は写経してください
    • TDDの背景や文脈は付録Cに書かれている

第1部の内容

  • 2つの仕様を満たすプログラムをTDDで開発していく
// ① 金額に数値を掛けて金額を算出する
$5 * 2 = $10
// ② 異なる2つの通貨を足し、為替レートに基づいて換算された金額を算出する
$5 + 10CHF = $10 (レートが USD:CHF = 2:1 の場合)  
  • 書籍では米ドル(USD)と瑞西フラン( CHF)を例にしている
  • 書籍ではJavaで書かれている
  • 第1部は全部で17章
  • 最後の17章はまとめなので、実際は16章まで

第1〜16章のコミットを追いながら説明

  • git log --oneline --reverse --pretty=format:"%s" でコミットメッセージを章ごとに表示
  • 書籍どおり、章の終了時点のコードがわかるようにGitHubのリンクを貼っておく
  • JavaとSwiftの言語仕様の違いとか、TDDの特徴で気になった点に注目していく

第1章

第1章 MoneyTestを作成
第1章 Dollarクラスを作成
第1章 Dollarクラスにイニシャライザ作成
第1章 Dollarクラスにtimesメソッド作成
第1章 Dollarクラスにamountプロパティを作成
第1章 テストを通すためにamountの初期値を10にする
第1章 重複の削除のためにamountの値を具体的にする
第1章 Dollarのイニシャライザでamountプロパティの初期値を設定する
第1章 timesの重複を削除するために5をamountに変更
第1章 timesの2のベタがきをmultiplierに変更
第1章 *=演算子をつかって重複を削除

第2章

第2章 Dollarの副作用でオブジェクトの状態が変更されてしまうが理想のテストを書く
第2章 もしもtimesメソッドから新しいオブジェクト返るなら
第2章 timesから新しいDollarオブジェクトを返せるような実装に変更する
第2章 timesからDollarオブジェクトを返す

第3章

第3章 equalsメソッドのテストを作成
第3章 equalsメソッドを作成してとりあえずtrueを返す
第3章 2つ以上の実例を作るために「$5 != $6」のテスト作成

第4章

第4章 Dollar同士を比較するようにしてテストの意図を明確にする
第4章 もう一方も同じようにDollar同士を比較する
第4章 一時変数のproductは不要なので削除してインライン化する
第4章 amountプロパティはprivateにして自分自身しか参照しなくて良くなった
第4章(番外編) Javaのequalsに相当する、Equatableの「==(lhs: Self, rhs: Self) -> Bool」を実装してテストを通す

第5章

第5章 ひとまずDollarのテストをコピーして、Francのテストを作成
第5章 DollarクラスをコピーしてFrancクラスを作成
  • 第5章終了時のソース
  • ①テストを書く→ ②コンパイラを通す→ ③テストを走らせ失敗を確認する → ④テストを通す → ⑤重複を削除する というサイクルで進めたい
  • ①~③を早く終わらせて④に出来るだけ早く着手したいから、DollarのテストとクラスをコピーしてFrancを作る
  • 要は、ただDollarコピペしてFrancにリネームしただけ

第6章

第6章 親クラスとしてMoneyクラスを作成
第6章 親クラスのMoneyにamountプロパティを引き上げる
第6章 Francの等価性のテストを忘れてたので追加する
第6章 FrancクラスもMoneyクラスを継承する
第6章 親のMoneyクラスにあるのでamountプロパティを削除
第6章 equalsメソッドのキャスト型をMoneyに変更する
第6章 Francクラスのequalsメソッドも親クラスのMoneyクラスに引き上げる

第7章

第7章 DollarとFrancは別の通貨であるというテストを追加
第7章 金額だけでなく、オブジェクトの型も同じなら等価とする
  • 第7章終了時のソース
  • 第6章の作業中に生じた疑問「DollarとFrancを比較するとどうなるのか?」をテストしてみる
  • 作業中に生じた疑問をテストにして確認するサイクルを紹介
    • 「あの条件・状態の時、どうなる?→テストコードで実験」という流れ
    • テストがあるとこういうの楽
  • ひとまずテストを通すようにコードを修正

第8章

第8章 timesメソッドの返値をDollarとFrancで同じにする
第8章 DollarのFactory MethodをMoneyに作成する
第8章 Dollarクラスへの参照を減らすために型宣言を親クラスのMoneyに変更する
第8章 DollarのFactory Methodの返り値の型をMoneyに変更する
第8章 Dollarを参照している箇所をFactory Methodに置き換える
第8章 Dollarと同じくFrancもFactory Methodを作成してFrancの参照をなくす

第9章

第9章 通貨(Currency)のテストを追加する
第9章 通貨名をサブクラスに格納する
 - Swiftではクラス内に同名で同型のプロパティとメソッドは定義できないので_を接頭辞につける
第9章 currencyを親クラスのMoneyに引き上げる
第9章 Francのイニシャライザで通貨名を渡せるようにする
第9章 Francのイニシャライザを呼び出している箇所のエラーを解消する
第9章 自身のイニシャライザを呼ばずに、親クラスのFactory Methodを呼ぶ
第9章 FrancのFactory Methodから通貨名を渡すように変更する
第9章 イニシャライザのcurrencyをプロパティに代入する
第9章 Francと同じ変更をDollarにも行う
第9章 サブクラスのイニシャライザを親クラスに引き上げる
  • 第9章終了時のソース
  • DollarとFrancのクラス自体を消し去りたいので、通貨(Currency)の概念を導入したい
    • じゃあ通貨(Currency)をMoneyに持たせて...とするのではなく、Moneyが通貨を持った状態のテストを先に書く
    • 書いたテストが成功するような実装を書いていく
    • 同じサイクルの繰り返し

第10章

第10章 timesメソッドで返すクラスを自身のイニシャライザを使って行う
第10章 ベタ打ちではなく、currency変数に置き換える
第10章 Franc型とMoney型の区別が必要なのか判断するためにtimesでMoneyを生成して返すように変更してみる
第10章 Moneyのtimesを抽象メソッドではなく具象メソッドに変更する
 - Swiftの場合、XCTAssertEqual failed: ("Optional(TDDForSwift.Franc)") is not equal to ("Optional(TDDForSwift.Money)") のエラーになる
第10章 エラーメッセージを少しマシなものにするためにデバック出力を編集する
 - SwiftはCustomStringConvertibleのdescriptionで、JavaのtoStringと同じ処理を実現できる
第10章 エラーになる前の状態に戻す
第10章 FrancとMoneyが等価であることをテストする
第10章 equalsメソッドでクラスではなく、通貨名を判定するように変更する
第10章 再びFrancのtimesメソッドでMoneyを返すように変更してテストを通す
第10章 Francと同じようにDollarもtimesでMoneyを生成して返すように変更する
第10章 timesメソッドを親クラスのMoneyに引き上げる

第11章

第11章 Factory Methodでサブクラスを初期化する必要はなくなったのでMoneyで初期化する
第11章 Dollarクラスを参照するコードはないので削除できる
第11章 等価性比較の過剰なテストは削除する
第11章 Francクラスの動作を確認するだけのテストとなったため、Francクラスと同時に削除する
第11章 掛け算の振る舞いをクラスごとにテストする必要はないので、不要な方の掛け算の振る舞いテストを削除する
  • 第11章終了時のソース
  • 子クラスを削除する準備が整った
  • 子クラスを削除して、過剰なテストを削除する(重複の削除)

第12章

第12章 足し算のテストを追加
第12章 plusメソッドを実装する
第12章 為替レートをもとに銀行が通過を換算(reduced)するようなテストを作成する
第12章 銀行を初期化する
第12章 2つの和を表現するExpression(式)を作成する
第12章 5ドルを作成して、$5 + $5 のテストを完成させる
第12章 Expressionを作成する
 - SwiftはprotocolでJavaのinterfaceを表現する
第12章 plusメソッドはExpressionを返すように変更する
第12章 MoneyをExpressionに準拠させる
第12章 Bankクラスを作成する
第12章 空のreduceメソッドをBankに実装する
第12章 ひとまずテストを通すためにreduceで10ドルを返す
  • 第12章終了時のソース
  • 掛け算はできたので、次は足し算の実装をスタート
  • やることは掛け算のときと同じサイクル
  • 為替レートの概念が複雑で熟考を要する
  • 12章から複雑になる
    • コミットの数が細かく章ごとのコミット数が多くなっていく
    • Expression(式)を思いつく人と、そうでない人に大きな差があるような気がしてならない(Kent Beck(筆者)も17章で式のメタファーを思いつくまでに多くの時間とプロセスを要したと述べている)
    • つまり、Expression(式)を思いつくまでテスト書いて実験するサイクルを繰り返せてことのようだ
    • 先にExpression(式)が出たけど、DollarができてMoneyができたのなら、SumができてExpressionじゃない?と思った
    • ドルとフランしか表現できなかったときがあったように、足し算しかできないBankができてもこの時点ではよかったのでは?

第13章

第13章 足し算のaugend(被加算数)とaddend(加数)のテストを書く
第13章 Sumクラスを作成する
第13章 plusメソッドでSumを返す
第13章 Sumクラスにイニシャライザを定義する
第13章 SumクラスにExpressionを準拠させる
第13章 Sumのイニシャライザでプロパティに値を代入してテストを通す
第13章 Bankのreduceのメソッドで足し算の結果をテストする
第13章 BankのreduceメソッドでSumのプロパティを足し合わせた値を使ってMoneyを生成して返す
第13章 BankのreduceをSumクラスへ移動する
第13章 BankのreduceメソッドにMoneyを渡したときのテストと、Moneyにキャストする処理をreduceメソッドに追加する
第13章 Moneyにもreduceメソッドを定義する
第13章 MoneyにもSumにもreduceメソッドがあるので、Expressionにreduceを定義する
 - Javaはinterfaceのメソッドはpublicになるが、Swiftはデフォルトのinternal(同モジュール内まで公開)で良い
第13章 Expressionにreduceを引き上げたのでキャストや型チャックが不要になったので削除する

第14章

第14章 2フランを1ドルに換算するテストを書く
第14章 ビルド通すためにBankにaddRateメソッドを空で実装する
第14章 フランをドルに換算するテストを通すために、Moneyのreduceメソッドでレートを計算する
第14章 為替レートをBankで管理できるようにreduceの引数にBankを追加する
第14章 Bankで為替レートの計算を行うrateメソッドを定義する
第14章 為替レートの計算をBankに任せる
第14章 配列の中身を等価だと扱ってくれるのかテストする
 - Swiftは等価だと判断するが、Javaは等価だと判断しない
第14章 先ほどのテストは削除して、Pairクラスを作成する
第14章 Pairクラスをハッシュのキーとして使うために必要なメソッド定義する
 - SwiftはHashableに準拠すれば辞書型(ハッシュ)のキーに使用できるクラスになる
第14章 Bankで為替レートを格納するローカル変数を定義する
第14章 為替レート設定時にレートを格納する
第14章 為替レートを検索されたときに対象のレートを返す
 - Swiftの辞書型(ハッシュ)から値を取り出すとき、値は必ずオプショナル(?)なので暗黙的アンラップ(!)する
第14章 同じ通貨を換算した場合にエラーになるので、同じ通貨を為替レートから検索する場合のテストを追加する
第14章 同じ通貨の場合は為替レートは等倍なので1を返す

第15章

第15章 異なる通貨を足し算して、どちらかの通貨に換算して結果を出すテストを書く
第15章 ひとまずビルドを通すために、Money型で宣言するがテストは通らない
第15章 Sumクラスで被加算数(augend)と加数(addend)を換算してテストを通す
第15章 被加算数と加数の型をExpressionに変更する
第15章 さらにイニシャライザの引数の型もExpressionに変更する
第15章 Moneyのplusメソッドの引数もExpressionに変更できる
第15章 Moneyのtimesメソッドの返り値の型もExpressionに変更できる
第15章 テストケースもMoneyのplusメソッドに渡す型をExpressionに変更する
第15章 fiveBucksの型もExpressionに変更する
第15章 Expressionにplusメソッド引き上げる
第15章 Expressionに準拠しているSumにもplusメソッドを定義する
 - 書籍どおりnilを返したいが、オプショナル型になると別メソッドと認識されるので、addedをとりあえず返す
第15章(番外編) 強制キャストしてMoneyにしないとテストが通らない
 - Swiftの==演算子はEquatableに準拠する型しか比較できず、Expressionはプロトコルなためできない

第16章

第16章 Sumクラスのplusメソッドのテストを書く
第16章 SumクラスのplusメソッドからSumを生成して返す
第16章 Sumクラスのtimesメソッドのテストを書く
第16章 SumクラスのtimesメソッドもSumを生成して返す
第16章 被加算数と加数はExpression型にしたので、Expressionにもtimesメソッドを引き上げる

第17章

  • 1〜16章までTDDのサイクルを以下のように表現してきた
    • ① 小さいテストを追加する
    • ② すべてのテストを動かし、失敗があることを確認する
    • ③ 変更を行う
    • ④ 再びすべてのテストを動かし、すべて成功することを確認する
    • リファクタリングを行い重複を除去する
  • TDDを教えるたびに著者は3つのことに驚く
    • テストを綺麗に機能させる3つのアプローチ。仮実装、三角測量、明白な実装
    • テストとコードの間の重複除去が設計を駆動する
    • テストの間のギャップを制御する能力。路面が滑りやすいならグリップを増し、路面が良いならより速く

まとめ

  • 第1部の総コミット数は122でした
  • 写経するのが一番理解が早いと実感した
  • Xcodeで全てが完結するのでTDDの写経は楽だった
  • TDDの問題ではないがテストが欲しい大きなプロジェクトほどiOSではビルドに長い時間がかかるのでスムーズにTDDができず歯がゆい

GithubKitForSampleを参考にしてQiitaKitForSampleを作ってみた

これはなに

この記事はiOS2 Advent Calendar 2017の5日目の記事です。

今年のiOSDCで注目を集めた iOSDesignPatternSamples を参考にしてiOSデザインパターンを勉強してる。このiOSDesignPatternSamplesは、GithubKit というライブラリを使って開発されている。

今回は、このGithubKitが面白かったので自分も真似して作ってみたという話。しかし、ただ真似するだけではコピペになるし学びが薄いので、APIをQiitaに変更して開発してみた。

github.com

github.com

先に作った感想

結論から先に言うと、とても勉強になったし、@marty-suzukiさんには感謝しかない。

具体的に良かったのは、「SwiftやiOSの新機能をさっと試すのに適当なサイズのサンプルアプリが欲しいとき、◯◯Kitというライブラリをフレームワーク化しておくとサンプルアプリを作りやすい」 ことに気づけたところ。

今までは個人で開発したアプリで新機能を試してたが、一度リリースしてしまうと既存ユーザーへの影響やデザインパターンとの調整を考えて、新機能を試すのが面倒になり何もしないことが多かった。

かといって、ゼロからサンプル用のアプリを作るのも面倒で、サンプルに適した形にするのもまた面倒だ。

結局、なにも試してない状態になってた。要するに、サボってた。

でも、この〇〇Kitとかを作るとcarthageでプロジェクトに取り込んでささっと適当なサイズのアプリにして新機能を試せていいかなと思い始めてる。

もちろん、試したい機能によって下準備とか別に必要だけど、それもフレームワーク化して 「新機能をすぐに試せる環境作りをしておくのが大切なんだ」 と実感した。

QiitaKitForSampleについて

github.com

本題に入る。GithubKitはSwift3の時代に開発されてたようで、Swift4の機能は使われていない。

というわけで、QiitaKitForSampleではSwift4の新機能の Codable を使ってAPIのリクエスト、レスポンス、モデルを書き換えてみた。

リクエスト(Requestable)

まずは、リクエストの部分。ResponseTypeをCodableにしてリクエストして返ってきたデータをレスポンスにデコードする static func decode(with data: Data, response: HTTPURLResponse?) throws -> Response<ResponseType> を定義した。

public protocol Requestable {
    associatedtype ResponseType: Codable

    static var baseURL: URL { get }
    static var notFoundText: String { get }
    
    var allHTTPHeaderFields: [String: String]? { get }
    var endpoint: URL { get }
    var path: String { get }
    var method: HttpMethod { get }
    var body: [String: Any] { get }
    
    static func decode(with data: Data, response: HTTPURLResponse?) throws -> Response<ResponseType>
}

レスポンス(Response<T: Codable>)

次にレスポンスではリクエストの static func decode(with data: Data, response: HTTPURLResponse?) throws -> Response<ResponseType> で処理するレスポンスのデコードメソッドを定義した。

singleはその名のとおりネストのないJSON(ex: {})の場合、unkeyedContainerは配列(ex: {},{})の場合に使う感じを想定して定義した。

ちなみに、.formatted(DateFormatter.ISO8601).iso8601 でもOKだが、iOS9~11の対応を想定して開発したので独自で定義したDateFormatterを呼んで渡してる。

public struct Response<T: Codable> {
    public let totalCount: Int
    public let values: [T]

    init(single data: Data, response: HTTPURLResponse?) throws {
        let strTotalCount: String = response?.allHeaderFields["Total-Count"] as? String ?? ""
        self.totalCount = Int(strTotalCount) ?? 0
        let decoder = JSONDecoder()
        decoder.dateDecodingStrategy = .formatted(DateFormatter.ISO8601)
        self.values = [try decoder.decode(T.self, from: data)]
    }
    
    init(unkeyedContainer data: Data, response: HTTPURLResponse?) throws {
        let strTotalCount: String = response?.allHeaderFields["Total-Count"] as? String ?? ""
        self.totalCount = Int(strTotalCount) ?? 0
        let decoder = JSONDecoder()
        decoder.dateDecodingStrategy = .formatted(DateFormatter.ISO8601)
        self.values = try decoder.decode([T].self, from: data)
    }    
}

モデル(User: Codable)

そして、レスポンスとなるモデルはスネークケースのキー名のみ、独自で定義すればOKなので簡潔になった。

public struct User: Codable {
    public let id: String
    public let name: String?
    public let profileImageUrl: URL
    public let followeesCount: Int
    public let followersCount: Int
    public let itemsCount: Int
    public let websiteUrl: String?
    public let location: String?
    public let organization: String?
    public let description: String?

    private enum CodingKeys: String, CodingKey {
        case id
        case name
        case profileImageUrl = "profile_image_url"
        case followeesCount = "followees_count"
        case followersCount = "followers_count"
        case itemsCount = "items_count"
        case websiteUrl = "website_url"
        case location
        case organization
        case description
    }
}

GET /api/v2/users/:user_id/followees

最後に、リクエスプロトコル(Requestable)とレスポンス(Response<T: Codable>)とモデル(User: Codable)を組み合わせて、フォローしているユーザーの一覧を返すリクエストは下記のようになった。

このUserFolloweeRequestを見るだけで、どのようなリクエストでレスポンスとして何が取得できるのか、はっきりするのが良いですね。

public struct UserFolloweeRequest: Requestable {
    
    public typealias ResponseType = User
    
    public static let notFoundText: String = "フォロー中のユーザーがいません"
    public let endpoint: URL
    public let path: String = "users/%@/followees"
    public let method: HttpMethod = .get
    public let body: [String: Any] = [:]
    
    public init(page: Int, perPage: Int, userId: String) {
        let basePathURL: URL = UserFolloweeRequest.baseURL.appendingPathComponent(String(format: path, userId))
        var components: URLComponents? = URLComponents(url: basePathURL, resolvingAgainstBaseURL: true)
        components?.queryItems = [URLQueryItem(name: "page", value: String(page)),
                                  URLQueryItem(name: "per_page", value: String(perPage))]
        self.endpoint = components?.url ?? basePathURL
    }
    
    // MARK: - ResponseType decode
    
    public static func decode(with data: Data, response: HTTPURLResponse?) throws -> Response<User> {
        return try .init(unkeyedContainer: data, response: response)
    }
}

Codableを使うことで、Swift3のときにResponseTypeに準拠させていたJsonをdecodeするためのプロトコル(JsonDecodableやJsonDecodeError)は不要となり、Codableが全てを処理してくれるようになった。

Codableへの移行が簡単だったのは、GithubKitの設計が良かったからだと思う。

終わりに

まだまだ発見がたくさんあったけども、それはまた別の機会にする。

当初の目的は、iOSDesignPatternSamplesでiOSデザインパターンを学ぶことだったので。

本家のiOSDesignPatternSamplesはGitHubKitなので、QiitaKitをつかってiOSDesignPatternSamplesの理解を深めていきたい。

ただコードを眺めたり、コピペするだけではやっぱり理解できないですね。

しかし、年内に終えるつもりだったのに間に合わない気がしてたぞ!!!!!!

xibとコードの両方から利用できるカスタムビューを作る

xibのイニシャライザと、コードのイニシャライザ

引き続き、下記のアプリで行ったことをアウトプット。

ボルダー

ボルダー

  • masashi sutou
  • スポーツ
  • 無料

xibのイニシャライザは init?(coder aDecoder: NSCoder) で、コードのイニシャライザは init(frame: CGRect) または独自で定義したイニシャライザになる。

上記のアプリを作成したとき、xibとコードの両方から利用できるカスタムViewが欲しくなった。

具体的に説明すると、Cellで画像を表示するViewはCellがStoryboardで定義されているのでxib経由で初期化したい。 一方、上記のアプリは画像や動画を複数同時にアップロード可能で画像Viewの数が一定ではないため、コードで初期化をコントロールしたい。

つまり、UIImageViewを継承したカスタムなイメージビューをxibとコードの両方から呼べるようにして、一つのカスタムビューで対応したいということ。

カスタムビューのイニシャライザ

MediaViewという名前のカスタムビューを作成して対応した。 xibとコードの両方から利用できるように下記のようなイニシャライザにした。 コードはSwift3です。

import UIKit

final class MediaView: UIImageView {

    private(set) var url: URL?
    private let indicator: UIActivityIndicatorView = UIActivityIndicatorView(activityIndicatorStyle: .gray)
    private let playImageView: UIImageView = UIImageView(image: UIImage(named: "play_icon"))

    init() {
        super.init(frame: .zero)
        isUserInteractionEnabled = true
        contentMode = .scaleAspectFit
        clipsToBounds = true
        translatesAutoresizingMaskIntoConstraints = false
        initialize()
    }
    
    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        initialize()
    }
    
    private func initialize() {
        
        indicator.hidesWhenStopped = true
        indicator.isHidden = true
        indicator.translatesAutoresizingMaskIntoConstraints = false
        addSubview(indicator)
        
        playImageView.contentMode = .scaleAspectFit
        playImageView.isHidden = true
        playImageView.translatesAutoresizingMaskIntoConstraints = false
        addSubview(playImageView)
        
        NSLayoutConstraint.activate([
            indicator.centerXAnchor.constraint(equalTo: centerXAnchor),
            indicator.centerYAnchor.constraint(equalTo: centerYAnchor),
            indicator.widthAnchor.constraint(equalToConstant: indicator.frame.width),
            indicator.heightAnchor.constraint(equalToConstant: indicator.frame.height),
            playImageView.centerXAnchor.constraint(equalTo: centerXAnchor),
            playImageView.centerYAnchor.constraint(equalTo: centerYAnchor),
            playImageView.widthAnchor.constraint(equalToConstant: playImageView.frame.width),
            playImageView.heightAnchor.constraint(equalToConstant: playImageView.frame.height)
        ])
    }
    
// 省略

xibとコードの両方で利用されるものをinitialize()というメソッドにまとめた。

コードで利用する場合はframeではなく、AutoLayoutでレイアウトを定義したかったのでtranslatesAutoresizingMaskIntoConstraints = falseにした。

今回はアプリの仕様上、初期化後にレイアウトが不変だったのでinit()で済ましたが、override init(frame: CGRect)にしてframeを渡しても良い。

まとめ

  • xibのイニシャライザは init?(coder aDecoder: NSCoder) で、コードのイニシャライザは init(frame: CGRect) または独自で定義したイニシャライザになる。
  • 例えば、xibとコードの両方で利用されるものをinitialize()というメソッドにまとめて、両方のイニシャライザから呼べば良い。

iOSのDependency Injectionについてわかった気がした

iOSDependency Injectionとは

最近、下記のアプリを作って気づいたことをアウトプット。

ボルダー

ボルダー

  • masashi sutou
  • スポーツ
  • 無料

ネット上に転がってるiOS開発におけるDIの話は、だいたい以下のような内容だと思う。

  • ViewControllerの初期化の時に、必要なプロパティを持つモデルや値をViewControllerへ注入すること
  • ViewControllerから見ると、モデルや値に依存していることになる

DIにより何が嬉しいのかというと、以下のような点になる。

  • 必須のプロパティを漏らすことなく、安全にViewControllerを生成し利用できる
  • 必須のプロパティが明示的になることで、アプリケーション全体の保守性があがる

今なら「なるほど、便利だなー!」と思うのだが、iOS開発しか経験がない僕は当初、Dependency Injection がまったくわからなかった。 僕は今の業務ではStoryboardを使用しない。ブログやLT資料の多くは、Storyboardを前提として内容が構成されている。 なぜDependency Injectionについてたくさん発表が行われているんだろうと、最初は不思議に思っていた。

コードで書くDependency Injection

業務ではStoryboardを使用しないが、個人開発ではStoryboardを使用して開発している。 個人開発は 「業務ではやらないことをやる」 をモットーにしているからだ。 コードでiOSを開発するとき ViewControllerの初期化は下記のように書くと思う。

final class WebViewController: UIViewController, UIWebViewDelegate {
    
    private var webView: UIWebView?
    private let url: URL
    
    init(url: URL, title: String) {
        self.url = url
        super.init(nibName: nil, bundle: nil)
        navigationItem.title = title.ex.localized
    }
    
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

// 省略

カスタムイニシャライザを定義して、引数をセットするプロパティは private let で外部からの変更不可にする。 そして、親のイニシャライザを呼ぶ前に子のプロパティをセットすれば、プロパティにデフォルト値を書かずにプロパティを宣言できる。 これで初期化時に何かしらの値が設定されていないと、ビルドエラーなのでurlが初期化のときに設定されることが保証される。

これで「ああ、WebViewControllerはurlとtitleが必要でurlは初期化時に設定されるんだなー」てのが理解できる。 下記のスクショのように書けば、Xcodeが補完して呼び出し側も何が必要なのか理解しやすい。

f:id:kurotyann:20170912004721p:plain

僕は普段、このような初期化の書き方をDIとは呼んでなく、そういう呼び方があることを知らなかった。ただ 「ViewControllerの初期化の時に、モデルや値を必要なプロパティに設定したい」 と思って書いていた。 今考えれば、ブログやLT資料のDIが目指す内容に近いことをしていると思う。もちろん、Storyboardは使えないけど。

Storyboard で書くDependency Injection

さて、これをStoryboardでやろとするとできない。カスタムイニシャライザが定義できないからだ。 初期化の後にプロパティへ値やモデルを設定しないといけない。つまり、プロパティは internalpublicopen にしないといけない。 この場合、下記のデメリットが発生する。

  • プロパティの設定忘れ
  • プロパティが途中で変更される可能性
  • 初期化で必須なのか、それともある状態のもとで必要なのか、プロパティの意図が曖昧になる

だから、 DIが必要なんです という話になる。これで初心者のiOSエンジニアにDIの意図が伝えられる気がする。 Storyboard で書くDependency Injection はだいたい2パターンで、OSSのライブラリを使うか、独自の protocol 等を定義して実装するのどちらか。

いろいろ見て個人的に一番良かったのは、@motokiee さんのDI実装だと思った。 元の資料のリンク削除されていたけど(@motokieeさんに確認をとって資料のURLを教えてもらった【10/11更新】)、下記のような実装だったと思う。

protocol DependencyInjectable {
    associatedtype Dependency
    static func make(withDependency dependency: Dependency) -> Self
}
  • DependencyInjectable をViewControllerに継承させる
final class FaqViewController: UITableViewController, DependencyInjectable {

    private var faq: Faq!
    
    // MARK: - DependencyInjectable
    
    struct Dependency {
        let faq: Faq
    }
    
    static func make(withDependency dependency: Dependency) -> FaqViewController {
        let vc = Storyboard.faq.instantiate(FaqViewController.self)
        vc.faq = dependency.faq
        return vc
    }

// 省略
  • 呼び出し側
    // MARK: - FAQに遷移
    
    private func transitionToFaq(_ faq: Faq) {
        let dependency = FaqViewController.Dependency(faq: faq)
        let vc = FaqViewController.make(withDependency: dependency)
        navigationController?.pushViewController(vc, animated: true)
    }

このDI実装の良いところは、とにかく他のDIに比べて軽量でわかりやすいところ。 そして、Dependency構造体の表現力がとても豊かでよかった。 今後、プロパティが増えたり、ある時に初期化するときはnilだったり型が違う場合でも表現しやすい。 さらに、下記のようにXcodeで呼ぶときも補完が出て、コードで書いた時と同様に何が必要なのかわかりやすい。

f:id:kurotyann:20170912012937p:plain

個人開発したBoulderはこのDI実装をフル活用して開発した。 この DependencyInjectable をさらに用途を限定して型を縛ったりしていたが、正直このままの方が使い勝手は良いと思った。

終わりに

もっと良いDIの実装方法は、必ずあるのでインプットは続けるし教えて欲しい。 ブログとかQiitaではStoryboardを前提とした記事が多いので、コードとStoryboardの両方から説明するものがあると独自性だしていけるかもと思ったり。 両方から説明することで、あるデザインパターンを理解しやすくなることはありえそうなので、頑張って書こうかな。

FirebaseつかってボルダリングのiOSアプリをリリースしました

リリースしたアプリについて

  • Firebaseつかって何か作りたかったので、趣味がボルダリングだし作ってみた

技術的な話

  • Swift3です、4ではないです
  • FirebaseのDBとStorage使ってデータとか画像とか動画とか保存してます
  • 業務ではNo Storyboardだけど、このアプリではStoryboardで出来ることはStoryboardでやった
  • いつもと勝手が違うしStoryboardの進化に知識と体がついていけてなかったりで戸惑った
  • みんなStoryboardで出来ることと出来ないことの住み分けはどうしてるんですかね

今後はどうするか

  • 個人開発は「業務ではやっていないことをやる」というルールを決めている
  • なので、そのとおりに色々挑戦していく
  • 今は、Firebaseのコンソールから直接DBさわるの辛いので、HTMLとCSSとJSでWebの簡易なサポートツールを開発中
  • HTMLとCSSとJSとか久しぶり過ぎて何やったらいいのか全然なんですが、色々思い出しながら進めてる
  • そこら辺が出来てSwift4が出たら、MVVM + Rx みたいな流行りのアーキテクチャを導入してみたい

最後に

  • はてブには何か技術的なことや、まとまったこと書く
  • 日々の備忘録できなものは WikiHubの日報でやっていくことにした

UdemyのサーバーサイドSwiftのコースをやってみた

Udemy にある下記のコースをやってみました。

www.udemy.com

概要

  • 有料コース(セールで1200円のときに購入)
  • 英語
  • Kituraの基本的な使い方と、Swiftで書いたサーバーサイドのコードをDockerでテストしたり、Bluemixにデプロイする方法が丁寧に紹介されている
  • 使用するDBはCouchDBというNoSQL
  • コース公開時の最新バージョンがSwift3.0だったので、コードが少し古い

良かった点

  • Xcodeでサーバーサイド側のコードが書けるのはとても気持ち良い
  • サーバーサイドのコードを書いてる気がしないというか、使い慣れたXcodeで開発するのでサーバーサイドを書く負担がすごく下がる
  • iOS開発ではほとんど利用しない、Docker や Swift Package Manager の基本操作が分かるのも良い

悪かった点

  • 講師の方の本業がiOSエンジニアではないようでコードの書き方はあまり良くない
  • クライアント側の実装は参考にしないほうが良いと思う

全体を通した感想

途中でXcodeの使い方やSwiftの書き方のレクチャーがあるが、サーバーサイドSwiftだけ興味ある人は飛ばして良い。俺も飛ばした。クライアント側の実装はあまり参考にはならなかったが、サーバーサイド側は良かった。

講中にSwift3.1がリリースされたので、コースで紹介されているOSSライブラリが全てバージョンアップしなければならくなった。バージョンを上げてもそのままでは動かないコードもあり、コース外で調べないといけないことが増えてしまった。しかし、そのおかげでサーバーサイドSwiftの理解がより深まったし、こういう発展途上の分野を少しずつ対応していくのはとても面白いので結果的によかった。

で、面白かったけど、これでiOSのサーバーサイドを全てSwiftで書く気になるのかと言われると、簡単なJSONを返すぐらいならいいかもというのが正直なところ。今はAWSやFirebaseなど、そもそもサーバーサイドを気にせずにアプリを開発する方法もあるので、わざわざSwiftでサーバーサイドを実装して作業量を増やさなくてもいい。でも、面白いのは本当です。

これから受講したいと思っている人は、最新のXcodeではビルドできなくなっているので、ハマりそうなところのコードを下記にのせておく。

コースの内容をSwift3.1に対応させてみる

  • だいたいはXcodeのサジェスト通りにやればなんとかなると思う
  • docker pull ibmcom/swift-ubuntu とかしてイメージを最新にしないと docker上のテストが失敗します
  • Package.swiftを更新したら、.build と Package.pins と xcodeproj を削除してから、swift build して swift package generate-xcodeproj しないと更新状態が反映されない
  • Swift-cfenv がコースの内容と、かなり乖離があるのでハマる人が多い
  • UdemyのQ&Aにいくつか質問があがってるので参考にすると良い

Package.swift

import PackageDescription

let package = Package(
    name: "FoodTruckAPI",
    targets: [
      Target(
        name: "FoodTruckServer",
        dependencies: [ .Target(name: "FoodTruckAPI")]
      ),
      Target(
        name: "FoodTruckAPI"
      )
    ],
    dependencies: [
      .Package(url: "https://github.com/IBM-Swift/Kitura.git", majorVersion: 1, minor: 7),
      .Package(url: "https://github.com/IBM-Swift/Kitura-CouchDB.git", majorVersion: 1, minor: 7),
      .Package(url: "https://github.com/IBM-Swift/Swift-cfenv.git", majorVersion: 4, minor: 0),
    ]
)

main.swift

import Foundation
import Kitura
import HeliumLogger
import LoggerAPI
import Configuration
import CloudFoundryEnv
import FoodTruckAPI

HeliumLogger.use()

let trucks: FoodTruck

do {
    Log.info("Attempting init with CF enviroment")
    let service = try getConfig()
    Log.info("Init with Service")
    trucks = FoodTruck(service: service)
} catch {
    Log.info("Could not retreive CF env: init with defaults")
    trucks = FoodTruck()
}

let config: ConfigurationManager = ConfigurationManager()
let controller = FoodTruckController(backend: trucks)

let port = config.port
Log.verbose("Assigned port \(port)")

Kitura.addHTTPServer(onPort: port, with: controller.router)
Kitura.run()

Config.swift

import Foundation
import LoggerAPI
import CouchDB
import Configuration
import CloudFoundryEnv

struct ConfigError: LocalizedError {
    var errorDescription: String? {
        return "Could not retreive config info"
    }
}

func getConfig() throws -> Service {
    let config: ConfigurationManager = ConfigurationManager()
    config.load(.environmentVariables)  // これがないとBluemix 上で環境変数が取得できない

    Log.warning("Attempting to retreive CF Env")
    
    let services = config.getServices()
    let servicePair = services.filter { $0.value.label == "cloudantNoSQLDB" }.first
    guard let service = servicePair?.value else { throw ConfigError() }
    
    return service
}