シリーズ修正可能なシステムのつづきです。
今、（７）サービス部分設計についてです。
まず、修正の必要性について考えました。修正の必要性は、
・入出力が変わった場合
は当然のこと
・副作用部分（ファイル、データベース等）
が変わっても起こります。ただし、データベースなどで、項目が増えたり減ったり、変更があったりしても、自分がその項目にアクセスしていなければ、基本的に影響しません。
で、これらにより、修正の必要があった場合、どうするかについてです。
■新サービスを作るか、引数を修正するか・・・
修正を行う場合、新サービスをつくる、まあ、新しいクラス、新しい関数、新しいメソッドを作るというケースと、既存の関数、メソッドを修正するケースがあります。
で、ここで、既存の関数、メソッドを修正する場合、何人かの人が参照していると、呼び出し元が修正した場合、呼び出し側も同時に修正しないと、コンパイルエラーになり、コンパイルできない。
で、あるメソッドが、呼び出し元でもあり、他のメソッドの呼び出し側でもあり、かつその呼び出し側が他のメソッドの呼び出し元で、めぐりめぐって、はじめの呼び出し元が、他の呼び出し側になっている・・・（＞＿＜！）
とか、分けわかんない場合だと、コンパイルできなくなってしまいます。
そこで、前の関数、メソッドを修正しないで、新規メソッドをつくり、その新規メソッドの中で、前のメソッドを呼び出す、前のメソッドはのこしておくなどという措置が必要になることもあります。
でも、そーやって新しいメソッドをがんがん作ってしまうと、新しいメソッドの乱立になります（さらに、そのメソッドを区別するのに、メソッド１、メソッド２などと、数字やバージョン名を付けるメソッドにすると、何が何なのか、どんなかんけいにあるのかわかんなくなってくる）
ちゃんと管理できれば、ダミー関数／メソッド（スタブ）を入れておいて、あるタイミングで、スタブをはずして、本物に切り替えるというのが、計画的に出来ますけど。。
なので、既存の関数、メソッドを修正する場合、はじめに修正部分のスタブをつくっておき、どのタイミングで、どのような場面で、スタブを使い、どのようなタイミングで、修正メソッドに置き換えるかの手順と計画が重要になってきます。単にCVSやSubversionで管理してます程度だと、混乱したことになったりします。
ってことで、あとは、こいつを、（８）設計して、（９）プログラミングします。
これはいいとして、次回は、（１０）テストのお話です。
アクセス
トータル
ランキング
