Zenn
💨

Rubyで学ぶプロキシパターン (Proxy Pattern)

2025/01/15に公開
Ruby
designpattern
proxypattern
プロキシパターン
tech

1. どんなもの？

プロキシパターンは、特定のオブジェクトへのアクセスを制御するために、そのオブジェクトの代理となるオブジェクトを提供するデザインパターンです。
このパターンを使うことで、実際のオブジェクトを直接操作せずに、アクセス制御や遅延初期化、キャッシュのような追加機能を柔軟に組み込むことができます。

2. 通常の実装方法と比べてどこがすごいの？

通常の方法

特定のオブジェクトを直接利用する場合、以下のような課題があります：

  • 大きなリソースを消費するオブジェクトをすぐに生成すると、パフォーマンスが低下する。
  • アクセス制御や追加機能を、オブジェクトごとに実装しなければならない。

例えば、以下のようなコードを考えます。

class RealObject
  def operation
    puts "Real object operation"
  end
end

real_object = RealObject.new
real_object.operation

上記の例では、RealObjectを直接利用していますが、生成コストが高いオブジェクトであったり、アクセス制御が必要な場合には柔軟性がありません。

プロキシパターンの利点

プロキシパターンでは、オブジェクトの操作を代理で行う「プロキシ」を利用するため、以下のような利点があります：

  • 実際のオブジェクトを必要になるまで生成しない。
  • アクセス制御をプロキシに一元管理できる。
  • キャッシュやログ記録といった追加機能を容易に組み込める。

以下の例では、プロキシを利用して遅延初期化を実現しています。

class RealObject
  def operation
    puts "Real object operation"
  end
end

class Proxy
  def initialize
    @real_object = nil
  end

  def operation
    @real_object ||= RealObject.new
    @real_object.operation
  end
end

# この時点ではまだRealObjectは生成されていない
proxy = Proxy.new
# operationメソッドが呼ばれた時点ではじ得てRealObjectが生成される(遅延初期化)
proxy.operation

このように、プロキシを通じてオブジェクトにアクセスすることで、柔軟な制御が可能になります。

3. 技術や手法の"キモ"はどこにある？

  1. 遅延初期化
    プロキシは、実際のオブジェクトを必要になるまで生成しません。これにより、リソースの効率的な利用が可能になります。

  2. アクセス制御
    プロキシを通じて操作を行うため、権限チェックや条件分岐を簡単に組み込むことができます。

  3. 追加機能の組み込み
    プロキシでキャッシュやログ記録、通知といった機能を実現でき、オリジナルのクラスを変更する必要がありません。

4. 実装例

例1: 認証を伴うアクセス制御

認証付きのリソースアクセスをプロキシで実現します。

class RealResource
  def access
    puts "Accessing real resource"
  end
end

class AuthProxy
  def initialize(user)
    @user = user
    @real_resource = nil
  end

  def access
    if @user.admin?
      @real_resource ||= RealResource.new
      @real_resource.access
    else
      puts "Access denied"
    end
  end
end

class User
  attr_reader :admin

  def initialize(admin: false)
    @admin = admin
  end

  def admin?
    @admin
  end
end

admin_user = User.new(admin: true)
proxy = AuthProxy.new(admin_user)
proxy.access # => "Accessing real resource"

normal_user = User.new(admin: false)
proxy = AuthProxy.new(normal_user)
proxy.access # => "Access denied"
  • 実装ポイント: アクセス制御ロジックをプロキシに集約することで、認証付きのリソース操作を安全かつ簡潔に実現しています。

例2: ログ機能の組み込み

ファイルへのアクセス操作を行うクラスFileResourceに対して、プロキシを使ってログ機能を追加します

class FileResource
  def read(file_path)
    puts "Reading file: #{file_path}"
    # 実際のファイル読み込み処理（省略）
  end

  def write(file_path, content)
    puts "Writing to file: #{file_path}"
    # 実際のファイル書き込み処理（省略）
  end
end

# このプロキシを介して、実際の操作が行われるたびにログを記録します。
class LoggingProxy
  def initialize(real_resource)
    @real_resource = real_resource
  end

  def read(file_path)
    puts "[LOG] Attempting to read: #{file_path}"
    @real_resource.read(file_path)
  end

  def write(file_path, content)
    puts "[LOG] Attempting to write: #{file_path} with content: #{content}"
    @real_resource.write(file_path, content)
  end
end

# オリジナルのリソースを生成
file_resource = FileResource.new

# ログ機能を組み込んだプロキシを作成
proxy = LoggingProxy.new(file_resource)

# プロキシを利用してログ機能を追加しつつ、オリジナルのクラスを操作します。
proxy.read("/path/to/file.txt")
# [LOG] Attempting to read: /path/to/file.txt
# Reading file: /path/to/file.txt
proxy.write("/path/to/file.txt", "Hello, World!")
# [LOG] Attempting to write: /path/to/file.txt with content: Hello, World!
# Writing to file: /path/to/file.txt
  • 実装ポイント:
    • オリジナルクラスの変更不要:
      • FileResourceクラスにはログ機能を追加していないため、元のクラスの設計や責務に影響を与えない。
    • プロキシで機能を拡張:
      • LoggingProxyがログ記録機能を担当することで、責務の分離を実現。
    • 柔軟性の向上:
      • プロキシを差し替えることで、他の追加機能（例: キャッシュ、認証）を簡単に組み込むことが可能。

5. 議論はあるか？

メリット

  • 遅延初期化やアクセス制御が容易に実現可能。
  • オリジナルのクラスを変更せずに追加機能を実装できる。
  • リソースの効率的な利用や、セキュリティ向上が期待できる。

デメリット

  • プロキシの導入によりコードが複雑化する可能性がある。
  • プロキシを介した操作が間接的になり、パフォーマンスが低下する場合がある。

議論

プロキシパターンは、リソース効率やアクセス制御が重要な場面で非常に有効ですが、設計の複雑さやパフォーマンスへの影響を考慮して適用する必要があります。

6. まとめ

プロキシパターンは、オブジェクトへのアクセスを制御し、追加機能を柔軟に組み込むための強力なデザインパターンです。

適切に利用することで、リソース効率やセキュリティを高める設計が可能になりますが、設計の複雑さを管理することが重要です。

GitHubで編集を提案

Discussion