ブリッジ パターンは、構造設計パターンを指します。ロジックを別の抽象クラスに移動することで、クラス ロジックの実装を抽象化できます。簡単そうですよね?
さまざまな種類のメッセンジャーにメッセージを送信できるスパム ボットを実装するとします。
共通のプロトコルを使用して実装します。
protocol User {
let token: String
let username: String
}
protocol Messenger {
var authorize(login: String, password: String)
var send(message: String, to user: User)
}
class iSeekUUser: User {
let token: String
let username: String
}
class iSeekU: Messenger {
var authorizedUser: User?
var requestSender: RequestSender?
var requestFactory: RequestFactory?
func authorize(login: String, password: String) {
authorizedUser = requestSender?.perform(requestFactory.loginRequest(login: login, password: password))
}
func send(message: String, to user: User) {
requestSender?.perform(requestFactory.messageRequest(message: message, to: user)
}
}
class SpamBot {
func start(usersList: [User]) {
let iSeekUMessenger = iSeekU()
iSeekUMessenger.authorize(login: "SpamBot", password: "SpamPassword")
for user in usersList {
iSeekUMessennger.send(message: "Hey checkout demensdeum blog! http://demensdeum.com", to: user)
}
}
}
次に、iSekU メッセンジャーのメッセージを送信するための、より高速な新しいプロトコルのリリースを想像してみましょう。新しいプロトコルを追加するには、iSekU ボットの実装を複製し、その一部のみを変更する必要があります。クラスロジックのほんの一部が変更されただけの場合、なぜこれを行うのかは不明です。このアプローチでは、DRY 原則に違反します。製品がさらに開発されると、新機能の実装におけるエラーや遅延によって柔軟性の欠如が顕著になります。
プロトコルのロジックを抽象クラスに移動して、Bridge パターンを実装しましょう。
protocol User {
let token: String
let username: String
}
protocol Messenger {
var authorize(login: String, password: String)
var send(message: String, to user: User)
}
protocol MessagesSender {
func send(message: String, to user: User)
}
class iSeekUUser: User {
let token: String
let username: String
}
class iSeekUFastMessengerSender: MessagesSender {
func send(message: String, to user: User) {
requestSender?.perform(requestFactory.messageRequest(message: message, to: user)
}
}
class iSeekU: Messenger {
var authorizedUser: User?
var requestSender: RequestSender?
var requestFactory: RequestFactory?
var messagesSender: MessengerMessagesSender?
func authorize(login: String, password: String) {
authorizedUser = requestSender?.perform(requestFactory.loginRequest(login: login, password: password))
}
func send(message: String, to user: User) {
messagesSender?.send(message: message, to: user)
}
}
class SpamBot {
var messagesSender: MessagesSender?
func start(usersList: [User]) {
let iSeekUMessenger = iSeekU()
iSeekUMessenger.authorize(login: "SpamBot", password: "SpamPassword")
for user in usersList {
messagesSender.send(message: "Hey checkout demensdeum blog! http://demensdeum.com", to: user)
}
}
}
このアプローチの利点の 1 つは、メイン アプリケーションのコードを変更せずに、抽象化されたロジックを実装するプラグイン/ライブラリを作成することで、アプリケーションの機能を拡張できることです。
戦略パターンとの違いは何ですか?どちらのパターンも非常に似ていますが、Strategy では *アルゴリズム* の切り替えについて説明しますが、Bridge では *任意の複雑なロジック* の大部分を切り替えることができます。
ソース
https://refactoring.guru/ru/design-patterns/bridge
ソースコード
https://gitlab.com/demensdeum/patterns/p>
