SwiftにおけるVisitorパターン（XXXへの共有オブジェクトの例）
Visitorパターンの実際の適用シーン分析（商品、曲、記事などをFacebook、Line、Linkedinに共有する場合）
Photo by Daniel McCullough
はじめに
「デザインパターン」というものを知ってから今まで10年以上経ちますが、完全に理解していると自信を持って言えることはまだできません。ずっとなんとなく理解している程度で、何度も最初から最後まで全てのパターンを見直しましたが、内面化できず、実務で使わなければすぐに忘れてしまいます。
私は本当にダメだ。
内功と技
かつて見た良い比喩があります。技術部分、例えばPHP、Laravel、iOS、Swift、SwiftUIなどの応用は、学習の敷居がそれほど高くありません。しかし、内功部分、例えばアルゴリズム、データ構造、デザインパターンなどは内功にあたります。内功と技術は相互に補完し合う関係にありますが、技術は習いやすく、内功は習得が難しいです。技術が優れていても内功が優れているとは限らず、内功が優れていれば技術も早く習得できます。したがって、相互補完というよりは、内功が基礎であり、技術と組み合わせてこそ無敵になると言えます。
自分に合った学習方法を見つける
以前の学習経験から、私に合ったデザインパターンの学び方は「まず深く理解してから広く知る」だと思います。まずいくつかのパターンを深く習得し、内面化して柔軟に使いこなせるようにします。そして、どの場面でどのパターンが適しているかを判断できる感覚を養います。その後、新しいパターンを一つずつ積み重ねて、最終的にすべてを習得します。実務の場面を多く探し、実際の応用から学ぶのが最良の方法だと考えています。
学習リソース
- Raywenderlich: iOS開発に特化した無料チュートリアルや記事が豊富に揃っています。
-
Hacking with Swift: Swift言語やiOSアプリ開発の初心者向け無料教材が充実しています。
-
https://refactoringguru.cn/ ：すべてのデザインパターンの構造、適用シーン、相互関係を完全に紹介しています
- https://shirazian.wordpress.com/2016/04/11/design-patterns-in-swift/ ：著者は実際のiOS開発の現場で複数のパターンの応用を紹介しており、本記事もこの方向で執筆します。
Visitor — 行動パターン
第一章はVisitorパターンについて記録しています。これはStreetVoiceでの1年間の仕事で掘り当てた金鉱の一つでもあり、StreetVoiceアプリ内でVisitorを活用してアーキテクチャの問題を解決した箇所が多くあります。この経験を通じてVisitorの原理と本質を理解できたので、まずは第一章でそれを書きます！
Visitorとは何か
まずはVisitorとは何かを理解しましょう。どんな問題を解決したいのか、そしてその構成要素は何かについて説明します。
画像は refactoringguru から引用しています。
詳細な内容についてはここで繰り返しませんので、まずは refactoringguru の Visitor に関する解説 をご参照ください。
iOS 実務シーン — 共有機能
例えば、以下の3つのモデルがあるとします：UserModel、SongModel、PlaylistModel。この3つのモデルに対して共有機能を実装します。共有先はFacebook、Line、Instagramの3つのプラットフォームです。各モデルが表示する共有メッセージは異なり、各プラットフォームが必要とするデータもそれぞれ異なります。
組み合わせシナリオは上の図の通りで、最初の表は各モデルのカスタマイズ内容を示し、二番目の表は各共有プラットフォームが必要とするデータを示しています。
特にInstagramはプレイリストを共有する際に複数の画像が必要で、他の共有先とは異なるソースが求められます。
モデルの定義
まず各モデルのプロパティ定義を完成させます：
// モデル
struct UserModel {
let id: String
let name: String
let profileImageURLString: String
}
struct SongModel {
let id: String
let name: String
let user: UserModel
let coverImageURLString: String
}
struct PlaylistModel {
let id: String
let name: String
let user: UserModel
let songs: [SongModel]
let coverImageURLString: String
}
// データ
let user = UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png")
let song = SongModel(id: "1",
name: "Wake me up",
user: user,
coverImageURLString: "https://zhgchg.li/cover/1.png")
let playlist = PlaylistModel(id: "1",
name: "Avicii Tribute Concert",
user: user,
songs: [
song,
SongModel(id: "2", name: "Waiting for love", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/3.png"),
SongModel(id: "3", name: "Lonely Together", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/1.png"),
SongModel(id: "4", name: "Heaven", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/4.png"),
SongModel(id: "5", name: "S.O.S", user: UserModel(id: "1", name: "Avicii", profileImageURLString: "https://zhgchg.li/profile/1.png"), coverImageURLString: "https://zhgchg.li/cover/5.png")],
coverImageURLString: "https://zhgchg.li/playlist/1.png")
何も考えずに行う方法
まったく設計を考慮せず、何も考えずに最も汚い方法でまず実装する。
周星馳 — 食神
class ShareManager {
private let title: String
private let urlString: String
private let imageURLStrings: [String]
init(user: UserModel) {
self.title = "Hi 素敵なアーティスト \(user.name) をシェアします。"
self.urlString = "https://zhgchg.li/user/\(user.id)"
self.imageURLStrings = [user.profileImageURLString]
}
init(song: SongModel) {
self.title = "Hi 今聴いた素晴らしい曲、\(song.user.name) の \(song.name) をシェアします。"
self.urlString = "https://zhgchg.li/user/\(song.user.id)/song/\(song.id)"
self.imageURLStrings = [song.coverImageURLString]
}
init(playlist: PlaylistModel) {
self.title = "Hi このプレイリストが止まらない \(playlist.name)。"
self.urlString = "https://zhgchg.li/user/\(playlist.user.id)/playlist/\(playlist.id)"
self.imageURLStrings = playlist.songs.map({ $0.coverImageURLString })
}
func shareToFacebook() {
// FacebookシェアSDKを呼び出す...
print("Facebookにシェア...")
print("[)](\(self.urlString))")
}
func shareToInstagram() {
// InstagramシェアSDKを呼び出す...
print("Instagramにシェア...")
print(self.imageURLStrings.joined(separator: ","))
}
func shareToLine() {
// LineシェアSDKを呼び出す...
print("Lineにシェア...")
print("[\(self.title)](\(self.urlString))")
}
}
特に言うことはありません。つまり、0の設計で全てがごちゃ混ぜになっています。もし新しい共有プラットフォームを追加したり、あるプラットフォームの共有情報を変更したり、共有可能なモデルを増やしたりすると、必ずShareManagerを修正しなければなりません。また、imageURLStringsの設計はInstagramがプレイリストを共有する際に画像の集合データを必要とするため配列として宣言しましたが、これは因果関係が逆で、要件に合わせて設計を変えてしまい、画像集合を必要としない他のタイプまで影響を受けてしまっています。
少し最適化する
ロジックを少し分離しましょう。
protocol Shareable {
func getShareText() -> String
func getShareURLString() -> String
func getShareImageURLStrings() -> [String]
}
extension UserModel: Shareable {
func getShareText() -> String {
return "Hi 素敵なアーティスト\(self.name)をシェアします。"
}
func getShareURLString() -> String {
return "https://zhgchg.li/user/\(self.id)"
}
func getShareImageURLStrings() -> [String] {
return [self.profileImageURLString]
}
}
extension SongModel: Shareable {
func getShareText() -> String {
return "Hi さっき聴いた素敵な曲、\(self.user.name)の\(self.name)をシェアします。"
}
func getShareURLString() -> String {
return "https://zhgchg.li/user/\(self.user.id)/song/\(self.id)"
}
func getShareImageURLStrings() -> [String] {
return [self.coverImageURLString]
}
}
extension PlaylistModel: Shareable {
func getShareText() -> String {
return "Hi このプレイリストがずっと聴き続けているものです \(self.name)。"
}
func getShareURLString() -> String {
return "https://zhgchg.li/user/\(self.user.id)/playlist/\(self.id)"
}
func getShareImageURLStrings() -> [String] {
return [self.coverImageURLString]
}
}
protocol ShareManagerProtocol {
var model: Shareable { get }
init(model: Shareable)
func share()
}
class FacebookShare: ShareManagerProtocol {
let model: Shareable
required init(model: Shareable) {
self.model = model
}
func share() {
// FacebookシェアSDKを呼び出す...
print("Facebookにシェアします...")
print("[.first))](\(model.getShareURLString())")
}
}
class InstagramShare: ShareManagerProtocol {
let model: Shareable
required init(model: Shareable) {
self.model = model
}
func share() {
// InstagramシェアSDKを呼び出す...
print("Instagramにシェアします...")
print(model.getShareImageURLStrings().joined(separator: ","))
}
}
class LineShare: ShareManagerProtocol {
let model: Shareable
required init(model: Shareable) {
self.model = model
}
func share() {
// LineシェアSDKを呼び出す...
print("Lineにシェアします...")
print("[\(model.getShareText())](\(model.getShareURLString())")
}
}
私たちは CanShare プロトコルを抽出しました。このプロトコルに準拠するモデルはすべて共有をサポートします。共有部分も ShareManagerProtocol として抽出しており、新しい共有機能はプロトコルの内容を実装するだけで済み、修正や削除をしても他の ShareManager に影響を与えません。
しかし、getShareImageURLStrings は依然として不自然です。さらに、もし新たに追加する共有プラットフォームのモデルデータが全く異なる場合、例えばWeChat共有では再生回数や作成日などの情報が必要で、それがそのプラットフォームだけに必要な場合、ここで混乱が生じ始めます。
ビジター (Visitor)
Visitorパターンを使った解決法。
// Visitor バージョン
protocol Shareable {
func accept(visitor: SharePolicy)
}
extension UserModel: Shareable {
func accept(visitor: SharePolicy) {
visitor.visit(model: self)
}
}
extension SongModel: Shareable {
func accept(visitor: SharePolicy) {
visitor.visit(model: self)
}
}
extension PlaylistModel: Shareable {
func accept(visitor: SharePolicy) {
visitor.visit(model: self)
}
}
protocol SharePolicy {
func visit(model: UserModel)
func visit(model: SongModel)
func visit(model: PlaylistModel)
}
class ShareToFacebookVisitor: SharePolicy {
func visit(model: UserModel) {
// Facebook シェア SDK を呼び出す...
print("Share to Facebook...")
print("[](https://zhgchg.li/user/\(model.id)")
}
func visit(model: SongModel) {
// Facebook シェア SDK を呼び出す...
print("Share to Facebook...")
print("[)](https://zhgchg.li/user/\(model.user.id)/song/\(model.id)")
}
func visit(model: PlaylistModel) {
// Facebook シェア SDK を呼び出す...
print("Share to Facebook...")
print("[)](https://zhgchg.li/user/\(model.user.id)/playlist/\(model.id)")
}
}
class ShareToLineVisitor: SharePolicy {
func visit(model: UserModel) {
// Line シェア SDK を呼び出す...
print("Share to Line...")
print("[Hi 跟你分享一位很讚的藝人\(model.name)。](https://zhgchg.li/user/\(model.id)")
}
func visit(model: SongModel) {
// Line シェア SDK を呼び出す...
print("Share to Line...")
print("[Hi 與你分享剛剛聽到一首很讚的歌，\(model.user.name) の \(model.name)、彼が再生中。]](https://zhgchg.li/user/\(model.user.id)/song/\(model.id)")
}
func visit(model: PlaylistModel) {
// Line シェア SDK を呼び出す...
print("Share to Line...")
print("[Hi このプレイリストはずっと聴いてるよ \(model.name)。](https://zhgchg.li/user/\(model.user.id)/playlist/\(model.id)")
}
}
class ShareToInstagramVisitor: SharePolicy {
func visit(model: UserModel) {
// Instagram シェア SDK を呼び出す...
print("Share to Instagram...")
print(model.profileImageURLString)
}
func visit(model: SongModel) {
// Instagram シェア SDK を呼び出す...
print("Share to Instagram...")
print(model.coverImageURLString)
}
func visit(model: PlaylistModel) {
// Instagram シェア SDK を呼び出す...
print("Share to Instagram...")
print(model.songs.map({ $0.coverImageURLString }).joined(separator: ","))
}
}
// 利用例
let shareToInstagramVisitor = ShareToInstagramVisitor()
user.accept(visitor: shareToInstagramVisitor)
playlist.accept(visitor: shareToInstagramVisitor)
一行ずつ見て、何をしたか説明します：
-
まず、Shareableというプロトコルを作成しました。これは、モデルが共有をサポートしていることを管理しやすくするためであり、Visitorに統一されたインターフェースを提供するためです（定義しなくても構いません）。
-
UserModel/SongModel/PlaylistModel は Shareable の
func accept(visitor: SharePolicy)を実装し、今後新たに共有対応のモデルが追加されてもプロトコルを実装するだけで済みます。 -
SharePolicyを定義し、サポートするModelを列挙する
(must be concrete type)
なぜvisit(model: Shareable)のように定義しないのか疑問に思うかもしれませんが、そうすると前回の問題を繰り返すことになります。 -
各ShareメソッドはSharePolicyを実装し、それぞれsourceに応じて必要なリソースを組み合わせます。
-
もし今日、WeChat共有機能が追加された場合、必要なデータは再生回数や作成日など特殊なものですが、既存のコードには影響しません。なぜなら、WeChatは具体的なモデルから自分が必要な情報を取得できるからです。
低結合、高凝集のプログラム開発目標を達成する。
以上はクラシックな Visitor Double Dispatch の実装例ですが、日常の開発ではこのような状況に遭遇することはあまりありません。一般的にはVisitorが一つだけの場合が多いですが、このパターンの組み合わせは非常に適しています。例えば、SaveToCoreDataの要件がある場合、accept(visitor: SaveToCoreDataVisitor) を直接定義し、Policy Protocolを多く宣言しなくても良いので、とても良い設計になります。
protocol Saveable {
func accept(visitor: SaveToCoreDataVisitor)
}
class SaveToCoreDataVisitor {
func visit(model: UserModel) {
// UserModelをCoreDataにマッピング
}
func visit(model: SongModel) {
// SongModelをCoreDataにマッピング
}
func visit(model: PlaylistModel) {
// PlaylistModelをCoreDataにマッピング
}
}
その他の応用例：保存、いいね、tableview/collectionviewのcellForRow….
原則
最後にいくつかの共通原則について述べます。
-
コードは人間が読むものであり、過剰設計は避けるべきです。
-
統一は重要であり、同じシーンや同じコードベースでは同じアーキテクチャや方法を使うべきです。
-
範囲が制御可能で他の状況が発生しない場合、この段階でさらに分割を進めると過剰設計と見なせます。
-
多くの応用、少ない発明；デザインパターンはソフトウェア設計の分野で数十年使われており、新しいアーキテクチャを作るよりも考慮されたシナリオが豊富です。
-
デザインパターンは学べますが、自分で作ったアーキテクチャは他人に学んでもらうのが難しいです。なぜなら、それを学んでも特定のケースでしか使えず、一般的な常識とは言えないからです。
-
コードの重複は必ずしも悪いことではありません。過度にカプセル化を追求するとオーバーデザインになる可能性があります。前述のポイントに戻りますが、プログラムは人が読むものです。したがって、読みやすく、低結合かつ高凝集であれば、それは良いコードと言えます。
-
パターンをむやみに改変しないでください。設計には必ず理由があり、無秩序に変更すると特定の状況で問題が発生する可能性があります。
-
回り道を始めると、どんどん遠回りになり、コードがどんどん汚くなります。
＠saiday に触発されて
参考資料
-
Swiftにおけるデザインパターン：Visitor (Visitorパターンの別の使用例)
-
iOSでの大規模ディープリンク（ステートパターン）
関連記事
Post は Medium から ZMediumToMarkdown により変換されました。
コメント