Column¶

注釈

ここはコラムページです．実績とは直接関係ないものの，プログラミングをしたりコードの品質を考えたりする上で知っておくと役に立つ事柄を紹介しています．

デメテルの法則¶

概要¶

デメテルの法則 （ Law of Demeter , LoD）または最小知識の原則（Principle of Least Knowledge）とは，ソフトウェアの設計，特にオブジェクト指向プログラムの設計におけるガイドラインです．このガイドラインは1987年の末にかけてNortheastern大学で作成されました．

この法則は「直接の友達とだけ話す（"Only talk to your friends"）」と要約できます．デメテルの法則の形式的な定義として，オブジェクト O 上のメソッド M が呼び出してもよいメソッドは，以下のオブジェクトに属するメソッドのみに限定されます：

O それ自身

M の引数に渡されたオブジェクト

M の内部でインスタンス化されたオブジェクト

O を直接的に構成するオブジェクト（ O のインスタンス変数）

もう少し具体的に言うと，他のメソッドの戻り値として返されたオブジェクトのメソッドの呼び出しを避けるべき，ということになります．例えばJavaにおいては，この法則は単純に「使えるドットは一つだけ」と言い表すこともできます．つまり， foo.bar.Method() という呼び出しは法則に違反していますが， foo.Method() という呼び出しは問題ありません．

デメテルの法則を適用することによって，ソフトウェアがよりメンテナンスしやすく，柔軟なものになりやすいという点が挙げられます．オブジェクトが他のオブジェクトの内部構造に依存することが少なくなるため，修正が容易にもなります．

参考文献: デメテルの法則 - Wikipedia

コード例¶

public class Foo {
// この例には２つのルール違反があります．

  public void example(Bar b) {
    // b は example のパラメータであるため，
    // このメソッド呼び出しは問題ありません．（下記定義の２番目に該当）
    C c = b.getC();

    // !!!
    // c は b から得られたものであり，このメソッド呼び出しは違反になります．
    // b に直接尋ねる， "b.doItOnC();" のようなメソッド呼び出しであれば問題ありません．
    c.doIt();

    // !!!
    // これも違反になります．実質的には上記の "c.doIt();" と同じです．
    b.getC().doIt();

    // コンストラクタの呼び出しであり，メソッド呼び出しではありません．
    D d = new D();

    // d は内部で新たにインスタンス化されたオブジェクトであり，
    // このメソッド呼び出しは問題ありません．（下記定義の３番目に相当）
    d.doSomethingElse();
  }
}

オブジェクト指向エクササイズ¶

概要¶

オブジェクト指向エクササイズとは，書籍「ThoughtWorksアンソロジー」で紹介されている，オブジェクト指向という概念を身につけるための訓練法です．以下に挙げる9つのルールを守りながらプログラムを書くことで，半ば強制的にオブジェクト指向を学習することが出来ます．このルールは，エクササイズのために作られたハードなルールであり，通常のプログラミング時に適用するような普遍的なルールではありません．

ルール1：1つのメソッドにつきインデントは1段階までにすること

ルール2：else句を使用しないこと

ルール3：すべてのプリミティブ型と文字列型をラップすること

ルール4：1行につきドットは1つまでにすること

ルール5：名前を省略しないこと

ルール6：すべてのエンティティを小さくすること

ルール7：1つのクラスにつきインスタンス変数は2つまでにすること

ルール8：ファーストクラスコレクションを使用すること

ルール9：Getter，Setter，プロパティを使用しないこと

Aveで用意している実績は，一部これらのルールを参考にして作成されています．

ルール1： Nest

ルール6： Lines of code

また，ルール4はこのページで紹介したデメテルの法則とも関連があります．

参考文献:

"ベア"プログラミング¶

概要¶

プログラムの開発手法として，ペア（Pair）プログラミングというものがあります．これは，2人のプログラマが1台の端末を使って共同でソフトウェア開発を行う手法です．実際にキーボードを操作してコードを書く人を「ドライバ」，もう1人を「ナビゲータ」と呼び，30分ごとや1日ごとといった一定時間ごとに役割を交替します．

このペアプログラミングを行うことで，以下のような利点がもたらされるとされています．

規範意識の増大：ペアプログラミングでは，個人の作業よりも怠けることなく作業を進める可能性が高くなります．
よりよいコード：相乗効果により設計の質が向上することが期待されます．
作業効率の向上：1人で作業するときとは流れが変わり，例えば次に何をすべきか考え込むといったことが少なくなります．

この「ペアプログラミング」をもじったデバッグ方法に，「ベア（Bear）プログラミング」というものがあります．これは，とある計算機センターのヘルプデスクに，テディベアのぬいぐるみが置いてあることに由来します．

皆さんは，こんな経験をしたことがありませんか．

自分の作っているプログラムが上手く動かず，どこにバグがあるのか考えても考えてもわからない．しかし，友人に助けを求めようとその悩みを説明した途端，自分の頭の中で問題点に気づき，解決策が浮かんだ．その友人は話を聞いてあげただけ．特にアドバイスもしていない．

悩みを言葉にする過程で頭の中が整理され，解決策が浮かぶことはよくあります．この悩みを相談する相手は，特に人間でなくてもかまいません．つまり，テディベアのぬいぐるみは，人間のスタッフに相談する前にまずはそのぬいぐるみ相手に悩みを相談してみなさい，というわけで置かれています．これだけでかなりの割合のトラブルが解決するといいます．

みなさんもプログラムが想定通りに動かずに困ったときは，ぬいぐるみに悩みを相談してみてはいかがでしょうか？

参考文献: