Clever Geek Handbook

命名：プログラマー向けガイド

命名101：モノの命名方法に関するプログラマーズガイド



名前の割り当ては、開発における主な困難の1つです。 名前について考え、悪い名前のコードを見つけようとするのにどれだけの時間を費やすかを計算することは不可能です。 そして、それがオブジェクト、メソッド、クラス、または他の何かであるかどうかは関係ありません。 コードを書くのではなく、コードを読むのにより多くの時間を費やしていることが証明された事実であると考えられているので、将来の良い命名規則はあなたの人生を楽にします。



良い名前はコードをより良く、よりきれいにします。 これらは、コードの各部分が何を担当しているかを直感的に判断するのに役立ちます。 将来、他の開発者があなたのコードを読みやすくなり、あなた自身も読みやすくなります。



以下では、適切な命名規則の重要性を説明し、役立つヒントを共有します。



抽象化のレベル



メソッドと変数は、目的に応じて名前を付ける必要があります。 名前を選択する前に、このコードが何を担当しているのかを理解してください。



メソッドがワルシャワとパリ間の距離の文字列値を返すときの状況を調べてみましょう。 



class DistancePresenter def to_s 'The distance between Warsaw and Paris is 1591 km' end end


コードはシンプルで、正しく機能しているようです。 また、要件を少し変更するとどうなりますか？ 距離をキロメートルとマイルで表示する必要があるとします。 これを行うには、 to_s



メソッドのキーワードkm



を置き換えるクラス変数を導入します。



新しい変数は、その値より1レベル上の抽象化と呼ばれる必要があります 。 これは、まず変数の目的について考える必要があることを意味します。 これは、より一般的な名前を付けるのに役立ちますが、同時にあまり凝っていません。 言い換えれば、名前は、その可能な値ではなく、変数の目的を想定する必要があります 。



では、私たちの新しい変数は何に責任があるのでしょうか？ オブジェクトにkmまたはmiという単語を提供します。 そのため、変数kilometers_or_miles



に名前を付けることができますが、そのような名前は、変数値自体と同じ抽象化レベルになります。 他の測定単位（たとえば、日数）を使用する機能が必要な場合、km_or_milesという名前は正しくありません。 より一般的なものが必要です。 キロメートルとマイルは単位であるため、変数unit



名前を付けることができます。 変数の目的よりも1レベル高い抽象化（より一般的な名前）であることがわかります 。 新しいクラスの実装： 



 class DistancePresenter def initialize(unit) @unit = unit end def to_s "The distance between Warsaw and Paris is 1591 #{unit}" end private attr_reader :unit end


ワルシャワとパリ間の距離は1591 kmですが、988マイルです。正しい値を返すメソッドを実装する必要があります。 ルールは、 unit



変数と同じです。 まず、解決すべき問題について考えてみましょう。 新しいメソッドは、値1591または988を返す必要があります。メソッドがどのようにそれを行うかは問題ではありません。 distance_warsaw_paris



と呼ぶこともできますが、変数と同じレベルの抽象化が得られます。 つまり、メソッド名は戻り値を想定します。 詳細すぎる。



将来、都市は、たとえばニューヨークやロンドンに変わる可能性があります。 そうすると、 distance_warsaw_paris



という名前distance_warsaw_paris



廃止され、コード全体で変更するのは面倒です。 距離だけを呼ぶ方が良い。 必要なのは、メソッドの本体の上の抽象化の1つのレベルです。



これで、メソッドは次のようになります。 



 class DistancePresenter def initialize(unit) @unit = unit end def to_s "The distance between Warsaw and Paris is #{distance} #{unit}" end private attr_reader :unit def distance if unit == 'km' 1591 else 998 end end end


抽象化レベルとクラス名



メソッドと変数は、それらの本体よりも高い抽象化の1つのレベルで呼び出す必要がありますが、 クラスの命名は別のルールに従います。 クラスを作成するとき、将来について考える必要はありません。 現在の仮定に基づいてクラスに名前を付ける必要があります。 車がボートの特性を取得できるとは想定していません。 したがって、アプリケーションで車が必要になった場合、クラスはVehicle



ではなくCar



と呼ばれる必要があります。



子クラスにも同じ方法で名前を付ける必要があります。 Car



クラスがある場合、特定のバージョン、たとえば、より高いペイロードを持つCar



マシンのCarPickup



を追加できます。



つまり、コンテンツの上の抽象化の1つのレベルに名前を付ける必要があるルールは、クラスではなくメソッドと変数に適用されます。



単独責任の原則



SOLID原則の1つでは、各モジュールまたはクラスが1つのことに責任を持つ必要があると述べています。 要素に関数が1つしかない場合、要素の名前を選択する方がはるかに簡単です。



たとえば、ボトルの唯一の義務は、液体の容器になることです。 （付録で）意図されていない移動や他の操作を行う能力をボトルに与える必要はありません。 動くことができる流体容器の名前は何ですか？ それほど簡単ではありません。ボトルは非常に単純な例です。 ウォーキング（そして場合によってはダンス、ランニング、トーク）ボトルを生産する代わりに、唯一の義務の原則に従うことをお勧めします。 液体の下にコンテナのクラスを1つ作成し、 Bottle



という名前を付けてから、ボトルを移動するクラスBottleCarrier



を作成します。



唯一の責任の原則は変数に適用されます。 メソッド、クラス、または別のタイプの変数の変数であっても、各変数は1つのことを行う必要があります。 クラスと同様に、1つのことを担当する変数の名前を考える方がはるかに簡単です。



小さい部分に分けます



優れたアーキテクチャは、優れたネーミングと切り離せません。 要素がどのタスクを解決するかを理解していれば、その名前を簡単に選択できます。 適切なアーキテクチャを作成するのに役立つ便利なテクニックがあります。タスクの各部分を小さなサブタスクに分割します。 その後、名前の選択がより速く簡単になります。



考えてみてください。目的を知っているときに、モジュールとオブジェクトに名前を付けた方が良いと思いませんか？ 車を説明する必要があるとしましょう。 各機能を1つのクラスにリストすることは困難ですが、それを多くの小さな部分に分割すると、すべての種類の機械コンポーネントを反映するクラスWheel



、 Tire



、 steeringWheel



などが得られます。 これらの小さなコンポーネントは名前を選ぶのが簡単で、その目的は簡単に判断できます。 したがって、コンポーネントに名前を付けるのが難しい場合、おそらくアーキテクチャにいくつかの欠陥があります。



まとめ



変数、メソッド、オブジェクト、またはクラスに一致するすべての良い名前は、遅かれ早かれあなたの生活を楽にします。 この記事では、適切な名前を選択するのに役立ついくつかの簡単な手法を示します。





適切な名前を選択することは難しくありません。 適切な名前を選ぶのに時間をかけることをお勧めします、それは価値があります。



* * *



この記事は、Sandy MetzとKatrina Owenによって書かれた本「 99 Bottles of OOP 」に触発されました。 良い本。 優れたコードリファクタリング手法など、多くの有用な情報をそこから学ぶことができます。


More articles:


All Articles