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

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

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

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

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

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

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

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

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

たとえば、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	与えられた Job や Task を実行する	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

まとめ

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