弊社平鍋が翻訳に携わった、メアリー・ポッペンディークの著書「リーンソフトウエア開発〜アジャイル開発を実践する22の方法〜」が7月23日、出版されました。ご愛読、よろしくお願いいたします。近頃ずっと「である調」の文章をしかも長々と書いていたので、自分の文体がわからなくなったような気がする梅田です。例外ケース』を紹介しました。今回は『変更の発散』を紹介しましょう。[変更の発散で見られる症状]・様々な要求で、同じクラスが変更されるこの症状が見られるということは、ずばりSRPに反しています。SRPでは、「1つのクラスは1つの責務を持つ」を原則とします。務を1つのクラスに持たせないこと。的に向かって凝集していること。色々な責務を抱えた巨大なクラスになってしまうことが多いでしょう。読む気も起きないクラスには、こういうのが多いですよね。務毎に『クラスの抽出』を行うことが大切です。今回は時計アプリをイメージしてみましょう。刻表示パネルを持ち、時刻表示を更新する、アラーム時刻を設定する、アラームを鳴らすといった責務を持っています。分析のクラス図を見てみましょう。----------------------------------------------------------------------例えば、現在の時刻表示がデジタル表示だとしましょう。これをアナログ表示も可能にするには、この時計クラスに変更が必要ですね。色を設定可能にする場合も、この時計クラスに変更が必要になります。このように、あるクラスが様々な要求で変更されるということは、SRPに反していると言えます。それでは、見た目に関する部分、アラームに関する部分をクラスとして抽出してみましょう。----------------------------------------------------------------------見た目を変更するときには文字盤クラスを変更し、アラームに関する変更を行うときにはアラームクラスを変更することで対処できます。張されることがあるかもしれませんが、その場合は時計クラスのみの変更でお終いですよね。囲を狭くすることができますし、変更すべき箇所がより明確にわかるようになります。ソースコードも読みやすくなりますね。今回は『変更の発散』を紹介しました。わかりにくい点や質問などありましたら、随時採り上げたいと思いますのでお気軽にご意見をお寄せください。(梅田)_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。