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

  • 1117
    いいね
  • 1
    コメント
この記事は最終更新日から1年以上が経過しています。

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

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

まとめ

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