トーフサロン

■[Objective-C] クラス命名のアンチパターン

mixi日記を見ていて「ああそうそう」と共感してたもんで、ちょっと考えてみた。 あまりパターンパターンと言うのは好きじゃないんだけど、まあいいや。 中には必ずしもアンチパターンな状況に結びつくとは限らないものも、個人的な見解のものもあります。 おまけに自分でもちょくちょくやってしまっているものもあります。

※追記 (2006/4/17): Objective-Cにおけるクラス命名パターンというのも書いてみました。こちらも合わせてどうぞ。

すべてはオブジェクト

概要

クラス名に "Object" をつける。

傾向

言われなくてもオブジェクトなんだからつける意味がない。

対策

ルートクラスやシステム特有の概念を表すクラス以外に "Object" をつけない。

器用貧乏

概要

クラス名に "Manager", "Controller" など管理や制御に関連する一般的な単語をつける。

傾向

どんな役割のメソッドでも一つのクラスに含まれてしまい、クラスの見通しが悪くなる。

対策

使わない。使う場合はこのような名前のつくクラスの役割を明確に定義しておく。

読めない空気

概要

クラス名に "Context" をつける。

傾向

クラス名からでは役割がわかりにくい。 なぜなら "Context" は他の概念 (クラス) との関係によって意味が変わるから。

対策

できるだけ別の名前をつける。 ただしコンテキストという言葉が定着している分野もあるし、 "Context" でしか表現のしようのないクラスもある。

リサイクル幻想

概要

クラス名に "Component" をつける。

傾向

再利用を前提としたクラスになりやすく、必要以上に抽象化してしまったり 再利用する必要がないのに無理矢理再利用することになったりする。

対策

無闇に再利用を考えない。 再利用を考える場合でも、抽象度によってクラス名や役割を決めておく。

業界用語

概要

長いクラス名を省略する。UtilitiesをUtilsと略したり、ObjectをObjと略したりする。

傾向

クラス名を見るとき、一瞬ではあるが省略された名前を考えなければならない。

対策

省略しない。クラス名は書くより読むことのほうが圧倒的に多いので、書きやすいことより読みやすいことを優先する。

コア・スキル

概要

クラス名に御大層な固有名詞やあまり使われない単語をつける。

傾向

実際の役割より過大に見え、必要以上に重要視してしまう。

対策

一般的な単語を使う。

一人はみんなのために、みんなは一人のために

概要

クラス名に "Utilities" をつける。

傾向

互いに関係ないメソッドの寄せ集めのクラスになりやすい。 インスタンスメソッドにすべきメソッドや、本来別のクラスに定義すべきメソッドまでまとめて定義される。

対策

できるだけ別のクラスにメソッドを振り分ける。