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

一方、インタフェースの宣言をする場合、そのインタフェースの名前に"形容詞"を用いることがあります（例：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`

まとめ

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