rights reserved. キレイなコードとは何か? n 誰でも理解コード? n 変更しやすいコード? n 重複が少ないコード? n 無駄な処理が含まれていないコード? n ちゃんとコメントが書かれているコード? n 会社の規約に沿ったコード? n 真の意味でオブジェクト指向を実践したコード? n etc… 3
rights reserved. キレイなコードを書くためには… n キレイなコードであると判断する基準はいくつもある n 個々の基準を満たすためにそれぞれのアプローチがある n キレイなコードの定義を⼀⾔で⾔い表す事は難しく、実践 ⽅法も⼀筋縄でいかない n この状況をわかりやすく表すために、キレイなコードを書 くためには「センス」が必要だと表現される n このキレイさの「センス」を⾝につけるには、無数の⼩さ な⼿法を知識として蓄え、⼀つ⼀つ丁寧に実践していく必 要がある 5
rights reserved. 意味のある名前をつける n 変数、関数、引数、クラス、パッケージの全てにおいて、注意深く、意図が 明確な名前を付ける n 偽や曖昧な名前を避け、コード中での意味が変わったら、速やかに意味に合 わせた名前に変える n エンコーディングが必要な名前にしない n クラス名には名詞を、メソッド名には動詞を使う n システム内で同じ抽象概念、コンセプトには同じ命名規則を適⽤して⼀貫性 を持たせる n ビジネスドメインの⽤語を使⽤する n 多少⻑くなっても意図を理解できる名前を付ける事を優先する 9 public List<int[]> getThem() { List<int[]> list1 = new ArrayList<>(); for (int[] x : theList) if (x[0] == 4) list.add(x); return list1; } public List<int[]> getFlaggedCells() { List<int[]> flaggedCells = new ArrayList<>(); for (int[] cell : gameBoard) if (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell); return flaggedCells; }
rights reserved. 関数を⼩さく保つ n ⼀にも⼆にも関数は⼩さく保つこと n 1つの関数は1つの事だけをきちんと⾏い、それ以外の事 を⾏ってはならない n 1つの関数は1つの抽象レベルにする • 抽象度の異なる処理が1つの関数内に混在しないようにする n DRY(Don't Repeat Yourself)原則を守る • 重複しているコードは、それだけで1つの役割を持っている 10
rights reserved. データとロジックの置き場所を同じクラスにする n オブジェクトは裏にあるデータを隠して抽象化し、データを操作 する機能を公開するためのもの • 全てのデータにsetter/getterを⽤意すると本末転倒 n データ構造の変更が必要になった場合でも、⾃クラス内の修正に 留める事ができる n デメテルの法則を守る・守らせる • オブジェクトを使⽤する場合、そのオブジェクトの内部についてしるべきで はない • データを隠蔽し、操作を公開する • 必然的に引数の受け渡しの数が少なくなる n データ転送オブジェクトの利⽤を避ける • レイヤ設計に伴って仕⽅がない場合にのみ利⽤ 16
rights reserved. オープン・クローズドの原則(OCP) n 「ソフトウェアの構成要素は、拡張に対して開いていて、修正に対し て閉じていなければならない」 n オープン:拡張に対して開かれている • アプリの仕様が変更されても、モジュールに新たな振る舞いを追加するだけでその変 更に対処できる n クローズド:修正に対して閉じている • モジュールの振る舞いを拡張しても、他のモジュールには影響が出ない、コンパイル なども不要な状態 n 多態性をうまく活⽤する 20 Client Server Client <<interface>> Server ServerImpl ClientはServerを参照している ため、Serverが変更されると Clientも何らかの変更、または 再コンパイルが必要 Clientはinterfaceを参照してい るだけなので、ServerImplの 振る舞いが修正されても変更 もコンパイルも不要
rights reserved. リスコフの置換原則(LSP) n 「派⽣型はその基本型と置換可能でなければならない」 • Tから派⽣したSがあり、Tを参照している任意の処理をSに置き換えても問 題なく動作する事を保証しなければならない n 例えば、派⽣クラスで親クラスのメソッドをオーバーライドして 振る舞いを壊している、例外を投げているなど n または、利⽤クラス側が多態性を無視して具象クラスにキャスト して利⽤している n この原則はコンパイルの仕組だけでは保証できない n 親と⼦でメソッド毎に事前条件、事後条件を取り決めてそれを守 るようにする • そもそも、できるだけ前後の処理に依存しない形でインターフェースを設計 する事 21