相手のやり方が何もしていないとき

著者らは、Michael FeathersがObject Metor Internationalのテクニカルコンサルタントであることを紹介します.彼の仕事は技術開発だけでなく、世界各地の技術チームの訓練、指導などの仕事にも参加している.彼はJUnitをC++に移行するCppUnitの初期部分と、FitCpp--C++版のFIT基礎テストフレームワークを開発したことがある.『Working Effectively with Legacy Code』の著者だ.
 
 
Michael Feathers
再構築の仕方は千差万別だ.大きな方法を分析するとき、私はまずその全体の構造を見て、心の中でどのように分解するかについて初歩的な感じがします.中の条件判断コードブロックは通常、問題があると思い、入手できる場所です.
1
2
3 if (...) {    ... }
このようなif文があるのを見て、私は選択に直面していることを知っています.このif文とそれに関連するコードブロックを新しい方法に抽出するか、関連するコードブロックだけを抽出することができます.私はこのようにするか、そうするか、どちらがいいか分かりません.これは文脈によって判断します.この条件文は非常に重要で、重点的に強調する必要がある場合がありますが、if文とそのコードブロックは、呼び出されたプログラムがよりきれいに見えるようにきれいに抽出することができます.しかし、私たちはどのようにしてこの抽出方法を呼び出しますか?
実際の例を見てみましょう
1
2
3
4
5
6 if (alarmEnabled) {     Alarm alarm = new Alarm();     ...     ...     alarm.sound(); }
if文全体とそのコードブロックをsoundAlarmという方法に抽出することができます.
1 soundAlarm();
これでいいですか.
多くの人の最初の反応は、今のコードは嘘をつくことがあると言います.警報が鳴ると教えてくれましたが、鳴らないことがあります.通常、このような嘘をつくコードがあるのは良いことではありません.そのため、別の再構築戦略を選択したほうがいいかもしれません.
1
2
3 if (alarmEnabled) {    soundAlarm(); }
でも、前ほどきれいには見えませんでした.
この二つの難しい選択はNullオブジェクトモードを思い出させた.Nullオブジェクトモードは、コードが嘘をついているように感じられる別の例です.プライマリ・コール・コードでは、メッセージがオブジェクトに送信されているのを見ましたが、驚くべきことに、対応する動作が発生していないことがわかりました.しかし、すべての人がこのような感じを持っているわけではありません.私のチームでは、Nullオブジェクトモードを大量に使用しています.コードの理解には、オブジェクトにXをすると言ったとき、しないことがあります.Xを実行するメッセージを送信することは、Xイベントが必ずしも発生しないことを意味します.これはこの対象によって決まる.
私の直感は私に教えて、これは何もありませんが、あなたはなぜこのようにするのかを理解する必要があります.これは非常に重要です.これは内部の理解問題です.
マルチステートに意味があるとすれば、少なくともオブジェクトは自分で自分を管理していると言っています.私たちはそれにメッセージを送ります.これはそれによって何をすべきかを決めます.これはオブジェクト向けのコアであり、Alan Kayの最初のオブジェクトに対する認識の一つでもある.メッセージはそれらの情報伝達にすぎない.このような観点は今では主導的な地位を占めていない.
このような抽出をより分かりやすくしたい場合、私は通常2つの戦略を持っています.1つのイベントを指す名前を使用したり、この操作を一般化したりします.この場合、イベントスタイルを使った過去の名前を選びます.
1 intruderDetected();//
このイベントスタイルのネーミング方法の利点は、動作ではなくイベント条件を強調することです.今、私たちは欲しいものをintruderDetected方法に入れることができます.
この操作を汎化することもできます.警報を思い出すよりも、私たちの状態に関する情報を世界に知らせることができます.
1 performNotifications();// performNotificationsのような名前を使うと、抽象的になります.ここの通知が1つなのか複数なのかは重要ではありません.肝心なのは、主調プログラムがこの動作をトリガーするが、動作が発生していないことを意味しないで嘘をついていると解釈できることだ.
それでも、私たちはそれが必ず何かをすることを示す方法名を永遠に信じないべきではないかと疑問に思っています.
もしそれがしなかったら、私たちはそれが嘘をついていると思っていますか?
牛の頭とこの状況について話しました.例:

if (save)

{

    //save1...

    //save2...

    //save3...

}

牛頭氏によると、この場合ifを一緒に提出するかどうかは、業務次第で、if文を言わなければ簡単で、saveDataという方法でifで呼び出し、if文を提出することにすれば、良い名前から解決できるという.メソッド名はsaveDataWhenNeedSaveと呼ばれていますが、これは単純な方法です.重要なのは、if文が抽出され、いつ抽出されないかをいつ決定するかです.
今日また考えてみましたが、if文を抽出するかどうかは、主にコード多重化の状況を見るか、saveDataに別の呼び出しがあり、save変数に基づいて保存するかどうかを決定する必要がない場合は、このifは明らかに持ち込む必要はありません.