|
||||||||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||||||||
| レベル5:柔軟性/拡張性が高いプログラム | ||||||||||||||||||||||||||
|
レベル5のプログラムのソースコードは、レベル4の問題点を克服し、柔軟性も拡張性も高いプログラムになっています。 |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
レベル5のプログラムには主に以下のようなポイントがあります。
|
||||||||||||||||||||||||||
|
表3:レベル5のソースコードのポイント |
||||||||||||||||||||||||||
| レベル5で終わりではない | ||||||||||||||||||||||||||
|
商品をクラスへ分割し、そのオブジェクトを共通に扱えるようにインターフェイスを決めたことで、ソースコード上からswitch文がなくすことができました。これより仕様変更に対しての柔軟性や拡張性が高いプログラムになっています。 しかし、レベル5で終わりではありません。さらなる仕様変更に対しても柔軟に対処できる設計として、「柔軟性・拡張性を意識したオブジェクト指向設計」を行うことと「案件に応じて、ゴールの見極め」があります。 |
||||||||||||||||||||||||||
| 柔軟性と拡張性を意識したオブジェクト指向設計 | ||||||||||||||||||||||||||
|
より多くの柔軟性と拡張性を求めれば、ソースコードを変更することなくシステムに修正を入れることができるようになります。 たとえば、初期化の部分です。これも「DI(Dependency Injection)コンテナ」と呼ばれる手法を用いれば、より柔軟性と拡張性を持った設計にすることができます。 |
||||||||||||||||||||||||||
| 案件に応じた、ゴールの見極め | ||||||||||||||||||||||||||
|
システムの拡張や変更が継続的に予想される場合や、あらゆるシステムで使用されるような場合、レベル5よりも高いレベルの柔軟性と拡張性が必要になります。 しかし、柔軟性と拡張性が高いプログラムが、常に求められるわけではありません。柔軟性と拡張性を見越したコーディングは、プログラムに無用な複雑さを持ち込んでしまいますし、実装にも時間がかかります。 |
||||||||||||||||||||||||||
| 上のレベルに上がるためには? | ||||||||||||||||||||||||||
|
サンプルプログラムを元に、ソースコードのレベルについて説明してきました。レベル3にあがるためには今後説明していく規約を勉強すればよいわけですが、それよりも上のレベル、つまりレベル3、レベル4、レベル5よりレベルを上げるためにはどのようなことをしたらよいでしょうか。レベルごとに説明していきたいと思います。 |
||||||||||||||||||||||||||
| レベル3を抜けるためには? | ||||||||||||||||||||||||||
|
レベル3のプログラムから上のレベルにあがるためには以下のようなテーマに取り組む必要があります。 |
||||||||||||||||||||||||||
| ひとつひとつの機能のまとまりを意識し、メソッド分割すること | ||||||||||||||||||||||||||
|
レベル3は、インデントやネーミングなどは守られていましたが、メソッド分割はされていないプログラムでした。機能に着目し、メソッド分割をすることは、「同じコードを二度書かない」「役割は1つに」につながります。 |
||||||||||||||||||||||||||
| メソッド分割のポイントは? | ||||||||||||||||||||||||||
|
メソッドが長いコードは、だらだらと頭に浮かんだコードを、そのまま実装したような印象を受けます。プログラムを書く時は、処理のブロックを考え、まずブロックをメソッドとして最初に定義することが大切です。文章を書く時の「まず目次を決める」ということと同じニュアンスです。 このようにコーディングはメソッドの骨組みができた後で、各メソッドの処理内容を記述していきます。そうすれば、各メソッドを見ることにより、仕様上に抜けがないか確認することができます。 |
||||||||||||||||||||||||||
| 同じコードを二度書かない | ||||||||||||||||||||||||||
|
同じコードを繰り返し書いてしまうのは、「仕様変更は有り得ない」とか、「仕様変更の時に、何ヵ所も修正することが苦痛ではない」といった考えがあるのかもしれません。 しかし、同じコードを二度書かなければ確実にコードの保守性が向上します。同じコードを何度も書いていると、仕様変更があった場合、そのコード全てに対して変更を行わなければなりません。 |
||||||||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||


