Posted at

うまくクラス名を付けるための参考情報

More than 3 years have passed since last update.

クラス名には、多くの場合"名詞"を用います。メソッド名の場合は動詞や助動詞を用いて命名しましたが、クラス名は何かしらの責務を持つモノとして捉えるため、名詞を用いることになります。

一方、インタフェースの宣言をする場合、そのインタフェースの名前に"形容詞"を用いることがあります(例:IterableCloseable等)。形容詞を用いることで、クラスの持つ性質を説明的に見ることができるようになります(Iterableな配列のList実装 -> ArrayList等)。

この記事は、どのような名詞や形容詞がクラス名やインタフェース名として用いることが出来るかを一覧し、できるだけクラスやインタフェースの役目を端的に表せるようなリファレンスとして活用できるものを目指していきたいと思います。

自分自身がクライアントアプリケーションのバックグラウンドを持っている為、多分にそこで用いる命名方法が含まれています。


ビジネスロジックを持つクラス

所謂モデルと称されるレイヤですが、そのモデルの中にも様々な役割を持つものが存在します。

モデルの名前として、ModelManagerという名前を使用して汎用的に使いまわすこともありますが、その実やることが多くなりがちでどんどん太っていってしまいます。モデルの中でも、様々なレイヤがあり、そのレイヤごとにうまく名前をつけることで役割を明確化し、その組み合わせでロジックを組み立てていけるようにしていきたいものです。


データソースを取り扱うレイヤ

たとえば、DB に SQL を発行するロジックを持っていたり、http 通信をしてレスポンスを得るロジックを持っていたりする部分という、データのやり取りをする上で基礎となる部分がデータソースのレイヤになります。言葉の意味通り、アプリケーションで使用するデータの出処となるモデルです。

概ね、何らかの I/O の基本的な機能(読み込み、保存、変更、削除、リクエスト等)を持つクラスたちです。

名前
補足

Client

HttpClient など、Server-Client な意味合いで使う

TwitterApiClient, QiitaApiClient

Gateway
API を叩くためのゲートウェイとして

TwitterTimelineGateway, QiitaAccountGateway

Store, Storage, Registry

DB を叩いたり、Disk I/O によるデータの永続化を行う部分に用いる

FavoriteSettingStore, DataStorage, ConfigRegistry

Cache
キャッシュ
TimelineCache

Log
ロギング。あるいは使用履歴の保存場所
UsageLog

History
履歴の保存場所
UsageHistory

Configuration, Preference, Setting

設定データの保存場所
TimelineConfiguration

必要であれば、I/O の基本的な機能を個別に分けて実装することもあるでしょう(できればそれらを統合したインタフェースを提供するか、はじめから統合したクラスで扱えるようになっているのがベストだとは思いますが……)。

名前
補足

Logger
ロギングを実行する
UsageLogger

Cleaner, Sweeper

データを綺麗に消す役割を担う

CacheCleaner, CacheSweeper


データを加工するレイヤ

データをそのまま使う場合もありますが、データを加工して使う場合もあります。

名前
補足

Filter
データの絞込を行う
TimelineFilter

Extractor
あるデータから別のデータを抽出する
MessageExtractor

Formatter
あるデータを整形して別のデータを出力する
MessageFormatter

Collector
データを集めてくる
AnalyticsDataCollector


データソースをラップするレイヤ

データを取ってきて、キャッシュに保存して、それをコントローラやプレゼンタのレイヤに返すまでの一連の流れをもつレイヤです。このレイヤのモデルを使う側から見たとき、取り出したデータがキャッシュから来たものかどうかは意識せずに使えるようになっていると、うまく役割の分離ができそうです。

名前
補足

Provider
データの提供者という意味で、上記のような DB、http 通信、キャッシュ等をカプセル化した上位レイヤのもの。あるいは Android でいう ContentProvider

TwitterTimelineProvider

Manager
データの管理をする。所謂モデルの良くある名前
AccountManager

Loader
データの読み込みを行う。あるいは Android における Loader

TimelineLoader

Logger
ログに書き出す、あるいは Log へのアクセスを提供する抽象レイヤ
RecentUsageLogger

Configurator
設定の初期値を保存したり、何らかのデータを元に自動で設定を保存したりするクラス
FirstSettingConfigurator

Migrator
バージョンアップなどでデータ構造に変更があるときのロジックを受け持つ
UserDataMigrator


非同期処理を扱うレイヤ

非同期処理を実行するクラスです。

名前
補足

Job, Task, Runnable, Executable

非同期処理のひとまとまりを扱う

UploadJob, MigrationTask

Runner, Executor, Worker

与えられた JobTask を実行する

UploadJobRunner, MigrationTaskExecutor

Aware
同期処理における何らかのコンテクストを保持し、管理されることを示すインタフェース(Spring Framework で用いられる)
ApplicationContextAware


フレームワークへのアクセスを統合するレイヤ

Facade パターンに基づく、他のフレームワークやサブシステムへのインタフェースを提供するレイヤです。

名前
補足

Facade

Facadeパターンの実装
BoundServiceFacade

Service
互換性のための実装をカプセル化しそれぞれの機能へのアクセスを実現するレイヤ
ApplicationControllerService

Resolver
ユーザの環境に応じた処理のルーティングをするレイヤ
ContentResolver


ビューの操作をするクラス

所謂コントローラと言われるレイヤです。どのようなフレームワークを採用するかによって左右されますが、概ね以下のような名前が付けられます。プレゼンタは厳密にはすこし異なる役割を持ちますが、ここに含めています。

名前
補足

Activity
Android で用いられる

Fragment
Android で用いられる

ViewController
iOS で用いられる

Controller
MVC における Controller

Screen.Presenter
MVP における Presenter。Mortarで用いられる。

Window


UI 上の動作を内包するクラス

特定の操作を抽象化し、その操作によって実行したい処理をまとめておくクラスです。インタフェースの名前としても使えるでしょう。

名前
補足

Action
操作そのものを表す

SubmitAction, CancelAction

Dispatcher, Handler

操作を受けて処理を実行する

SubmitActionDispatcher, UserActionHandler

Listener, Watcher

操作を監視する。Observer パターンの実装名

ClickListener, TextEditWatcher


まとめ

言語やフレームワークによっても作法や規則が異なるため、一概にこれが良い!というものではありませんが、設計やリファクタリングの際に、どのようにレイヤを切り分けるかを考える上でも、どんな名前をつけるかは重要です。いろいろ列挙してみましたが、有名なデザインパターンやフレームワークで用いられる名前をそのまま用いるほうが良い場合もあります。できるだけ端的にそのクラスの役割を表せるような名前を付けられるようにしたいものです。