「スティーブ・ジョブズ２」読了

ジョブズ熱もいくらか冷めた頃ということで、書くには良い時期かな。
スティーブ・ジョブズの自伝『2』について。
『1』ではジョブズの幼少時代からネクストまで、主に人間性について書かれていた。
『2』ではアップルの復帰から、ジョブズの成し遂げた多くのことについて書かれている。

目次

・あるべき姿のキーボード
・アップルストア
・選択と集中

あるべき姿のキーボード

『1』を読むとジョブズは変人を超えて、一般的にいう「どうしようもないヤツ」だと感じる。
ただ、一生を通して正しいものを作るという芯はブレず、情熱も最後まで失わなかった。

この学生に、マッキントッシュのキーボードにサインしてほしいと頼まれたジョブズは、自分が会社を追い出されたあと、マックに追加されたキーを外していいならと承諾。車の鍵を取り出すと、まず、かつて自分が拒否したカーソルキー、４つを取り除く。続いて、最上段に並ぶファンクションキー（F1,F2,F3……）も外してゆく。
「僕は、あるべき姿のキーボードを世の中に広め、世界を変えていきたいとおもっているんだ」
とまじめな顔で宣言すると、ジョブズは、見るも無残になったキーボードにサインした。（P23-24）

アップルに復帰する前のエピソードだが、これこそジョブズという人をよく表している。同時に、アップルが如何に迷走していたかも。
ジョブズには製品に対するビジョンがあり、ジョブズ抜きのアップルにはそんなものは無かった。
ただし、それではジョブズの方が正しいのかというと、一企業としてはそういうわけでもない。
事実『1』ではジョブズのビジネス上の失敗がいくつも書かれており、決して順風満帆ではないことがわかる。

ちなみに、ジョブズが関与しているはずの今のMacのキーボードにはカーソルキーもファンクションキーもある。
時の流れ、時の試練によって、今ではどちらも必要であると判断したのだろう。
今のMacの機能を考えると、それらがないと明らかにキーが足りなくなるし。
（Macではファンクションキーをコンビで押すことによって音量や画面の明るさの調節、音楽プレイヤーの操作などができる。）
私が知ってる中で、今買えてどちらもないのはHHKBProくらい。HHKBLiteにはカーソルキーがあって、私は重宝している。
参考　Happy Hacking Keyboard Lite2を買ったらWindows+Lが押せなくて - holyppの日記

アップルストア

本書でもう一つ取り上げたいのはアップルストアについて。
なぜなら、アップルのやっていることで、私が唯一納得できなかったものだからだ。
具体的には、銀座と渋谷にあるアップルストアの存在意義がわからなかった。

『誰が、わざわざ銀座や渋谷にまでいって、Macを買うんだよ』と思っていたのだ。

もしかして、儲かってるから道楽でやってるのではないかと思っていたくらいだ。
もちろんそれは間違いであり、アップルストアの存在意義と、その成り立ちについては『2』にしっかりと書かれている。
目的はやはり「わざわざ出向いてMacを買ってもらう」ためにあるわけではなかった。
私は郊外の地代の安いところに大きい店舗を構えたほうがいいと思っていたが、それに対する答えがそのまま書いてあった。

「ウチの製品を見に１０マイルも運転させるのは難しくても、１０フィート歩いてもらうことならできるはずだ」
「十分に入りやすい雰囲気を作れれば、通りかかったとき、興味を引かれて立ち寄るはずだ。製品を紹介するチャンスさえ得られればこっちのものさ」（P134）

これを見ると、これこそが「アップルらしい戦略」だと思えてしまうから不思議だ。
銀座や渋谷を歩く人が、ふらっと入ってくれればいい。『製品を紹介するチャンスさえ得られればこっちのものさ』ということだ。

そのアップルストア１号店は2001年5月19日、ヴァージニア州タイソンズコーナーにオープンした。
ジョブズはそのために店舗のプロトタイプを6ヶ月も作りこみ、そして壊し、また作り直した。
最初のプロトタイプは、パワーマック、iMac、iBook、パワーブックと製品ラインごとの展示としていたが、そろそろ完成かという頃にロン・ジョンソンは「4種類のコンピュータを中心に製品を配置するのではなく、『人々がしたいであろうこと』を中心に配置するべきではないか」と訴える。
ジョブズは一度「６ヶ月も必死こいてやってきたのに、それを全部ぶん投げようというのか！」と声を荒げるが、後から「ロンが正しいのはあきらかだった」と言うようにオープンが遅れてもやり直すことを決める。

「我々は根本的な間違いを犯しているとロンは主張している。製品を中心にするのではなく、人々がしたいことを中心にレイアウトすべきというのが彼の考えだ。」（P139）

2000年の話だが、これは今でも通じるはずだ。
アップルストアは細部にもジョブズのこだわりが行き届いており、階段については特許を申請しているほど。
2010年にはジョブズが「この店は、単位面積あたりの売り上げで世界最高だ」と言うほどの店舗となった。

私が「道楽でやってんじゃないか」なんて思っていたのはとんでもない勘違いだったわけだ。
とはいえ、休日の銀座アップルストアは人が多すぎ、ごちゃごちゃしていてあまり行きたいものではないけれど。

選択と集中

最後にジョブズの選択と集中について。
ジョブズが復帰したときのアップルは製品の種類が多すぎた。
そこでジョブズは「友達にはどれを薦めるべきなんだい？」と尋ねる。すぐに答えが返ってこないことに対し、

「君たちは優秀だ。優秀な人間がこんなお粗末な製品に時間を無駄遣いしちゃいけない」（P87）

そしてホワイトボードに「田」と書き

「我々が必要とするのはこれだけだ」そう言いながら、升目の上には「消費者」「プロ」、左側には「デスクトップ」「ポータブル」と書きこむ。各分野ごとにひとつずつ、合計４種類のすごい製品を作れ、それが君たちの仕事だとジョブズは宣言した。（P88）

これがパワーマックG3、パワーブックG3、のちのiMac、のちのiBookとなるのだが、ここまでシンプルなメッセージを私は知らない。

他にも本書ではジョブズの最後の仕事まで、つまりiTunes、iPodそしてiPhone、iPadとクラウドについて、また闘病と家族についてもしっかりと書かれている。
大筋ではそうだろうなというところが多かったが、ここまで音楽が好きだということには驚く人もいるかもしれない。
ページ数も400を超え中身も濃いので、2011年の本としては一番だと思う。私は滅多にハードカバーの本は買わないのが、これは買って良かった。
『1』も読むべきだが、1冊だけというなら『2』の方が良いかも。

「スティーブ・ジョブズ１」読了 - holyppの日記

『風の歌を聴け』村上春樹

ストーリーは、Wikipediaによると『20代最後の年を迎えた「僕」は、アメリカの作家デレク・ハートフィールドについて考え、文章を書くことはひどく苦痛であると感じながら、1970年の夏休みの物語を語りはじめる。』というもの。
私はAmazonにある（たぶん正式な）説明よりも、こちらが好みだ。

私が村上春樹の本を読むのはこれが10冊目くらい、あまり読んでないが全く読んでないということもない数だ。
本作は評価の良いデビュー作「らしい」という印象があったが、読んでみると今までで一番わからなかった。
つまらないというわけではなく、よくわからない。

そこで、いくつかの書評、レビューサイトなどをまわって理解してみようと思った。
（同じ本を読んだ人の感想や、それに付随する情報を部屋に居ながら調べられるというのは、とても良い時代になったものだ。）
それらをいくつか読むと、評価が良いか悪いかでいえば、やはり良い方だった。
村上春樹は熱心なファンも多く、そういうサイトには細かい仕掛けの解説や、さまざまなエピソードが書かれている。
中でも最も大きな仕掛け、デレク・ハートフィールドについては、私も「ほぉ！」と驚かされたが、そこまで見ても、やはり「この作品はすばらしい」とはなかなか思えなかった。
小説は「こんな仕掛けがあって、このシーンはこういうことを暗示していて、この言葉はあれの暗喩で」など教えられても、心からの評価は変わらないものだ。
（とは言っても、今のようなインターネットが無い社会ではデレク・ハートフィールドという魔法は効果抜群だったと思うし、実際そうだったようだ。それだけでもすごい作品と言える。）

ここまで勉強したところで、やはり「四部作」を読んで再度評価（というかなんというか）をするしかないなと行き当たる。
１９７３年のピンボール、羊をめぐる冒険、ダンス・ダンス・ダンスまでだ。今もやもやしているものが、少しずつ形になっていけばと思う。
年内は積んでる本があるので、来年のどこかのタイミングで3作読むことにする。
結局本書のストーリーについては全く触れなかったのだが、あとがきを含めても160ページの短い話であるし、もやもやしてるいるし、本エントリはここで終わることにする。

上述のデレク・ハートフィールドについては『本書を読んだ後に』Wikipediaなどを見て欲しい。
デレク・ハートフィールド - Wikipedia

「スティーブ・ジョブズ１」読了

１を読み終わった。ジョブズの伝記ではあるが、私はウォズニアックが出てくる度に興奮した。
残念ながら、後半ではウォズはほとんど出てこない。その役割はジョン・ラセターが代わって引き受ける。
大きく見ると、前半はウォズのパトロンとして、後半はラセターのパトロンとして活動したことがジョブズの成功の素だった。
おそらく２ではそういう色が薄まり、ジョブズ自身の活動がメインとなっていくのだと思う。
ここでは、本筋とは違うが主にウォズに関する箇所について書いていく。

アタリのボーナス

ウォズは親から、エンジニアリングが世界で最も重要なものであること、正直であること、そして中庸が一番だということを教えられて育つ。
最初の有名なエピソードは、アタリでジョブズの仕事をウォズが手伝うシーンだろう。
ウォズは「複数のエンジニアが２〜３ヶ月かけてつくるゲーム」をたった1人、4日完徹で完成させる。
ただその天才性よりも「そのボーナスをジョブズがちょろまかした」というエピソードの方が有名で、それについてP101にいろいろと書かれている。
ウォズは「正直に言ってくれたらよかったのにとは思うよ。お金が必要だと言ってくれればぼくの分はあげたのに。彼は友達で、友達は助け合うものなんだから」と言っている。後述のIPOの件も含め、ウォズの人柄が表れている。

アップル設立

アップルIを作ったときも、ウォズはみんなにタダで配ろうと思っていた。
そこでジョブズが「売ったほうがいい」と言い、会社を作ることになる。
ウォズは当時貧乏だったが、お金が儲かるかどうかよりも、自分の会社が持てることに興奮する。

「自分たちがそんなことをすると思っただけで元気が出たよ。親友とふたりでいっしょに会社をはじめる。すごい。すっかりその気になったよ。やるしかないよね」

そしてウォズは電卓を売り、ジョブズは車を売ってアップルを設立する。
当時の二人がどんなものかはP115でロン・ウェインがこう言っている。

「まったく似てないふたりでしたが、パワフルなチームでした」
ジョブズは悪魔が憑いているのではないかと思うような言動をすることがあったが、逆にウォズはナイーブで、天使とたわむれているような人間だった。

かといって、ウォズは決して自分の能力に無自覚なわけではなく、役割分担をわかっていた。
ウォズの父が、ジョブズに「おまえはたいしたことをしていない。なにも作っていないじゃないか」と言うシーンがある。
ジョブズは泣きながら、パートナーシップを解消してもいいとウォズに提案するが、ウォズはそのままで良いと言う。

一方、さすがにギークらしく、ジョブズを相手に強く意見をいうこともあった。
アップルIIのとき、ジョブズは拡張スロットを2本にすると言ったが、ウォズは8本を主張した。

「ぼくが人と争うことはめったにない。でも、このときだけは違った。『どうしてもそうしたいのなら、どこかほかでコンピュータを手に入れろよ』って言ってやったんだ。」

開発者としては気持ちの良い言葉だ。こんなに良いものは自分以外に作れるわけがないというわけだ。
ただ、それに続けて「あのころのぼくは、こう言えるだけの立場にいた。でも、ずっとそうだったわけじゃない」とも言っている。
結局、アップルIIの拡張スロットは8本になる。
アップルのIPOのときも、ジョブズはとてもシビアだったが、ウォズは自分の株式を職位が高くない社員40人に安く売った。それは家を買えるくらいの額になった。
IPOの後は、あまりウォズの話は出てこなくなる。

その後

アップルIPO後、ジョブズは紆余曲折がありつつもマッキントッシュを作ることになる。
ウォズはしばらくアップルIIの部署で開発を続けるが、退職する（結局、アドバイザーとして留まることになる）。
ジョブズはアップルを追い出され、NeXT、ピクサーと活動の場所を変えていく。
NeXTでは結果的に失敗に終わり、ピクサーで資金が底を付きそうになる。
それでもジョブズはジョブズでありつづけ、ラセターとともにトイ・ストーリーを成功させる。
その間に結婚もするし、子供も生まれる。
そこまでが「スティーブ・ジョブズ１」で書かれている。

率直な印象を言うと、ジョブズはLSDもやるし風呂には入らないし嘘はつくし人の話を聞かない。
どうにもこうにもダメ人間という印象が拭えないが、強さがある。
ここぞというときの強さ、それに人を惹きつける力がある。
２は、アップルに戻るところから。ここからが本番だと思っているので、続けて、楽しく読んでいきたい。

「スティーブジョブズ」を読みはじめた

とても良い本だと思う。雰囲気としては「福翁自伝」のようだと感じる。
常識や決まりなどには捕われず自分がやりたいことをやる。その快活さと大きな志とが、福沢諭吉にも、ジョブズにもある。

読んでみて、私が意外だなと思ったのは大きく二つ、まずは「天才」では無かったこと。
リード大に入った頃はカリスマ性というほどのものは無く、後天的なものだということが書かれている。
もうひとつは、感情表現が下手だということ。
これは、意外ではないという人も多そうだが、ウォズのおやじにいろいろ言われて泣いてしまうところなど、クールとは程遠い人物であったようだ。
また、読んでいるとジョブズよりもウォズの方に感情移入してしまうところが多いのだが、エンジニアの大半はそうなんじゃないかなと思う。

ジョブズ関連の本を多く読んでいる人には「新しい内容はない」とも言われているようだが、私はそういう本は読んでいないし、楽しく読めている。
もちろん例の「祝辞」や、いくつものプレゼンテーションは見ているが、ちょうどそれが前提となって、すんなり読めている。
逆に、それらを見ていないのなら、その都度Youtubeを見ることになるのだろう。

あーだこーだ言わずに、まずは読んでおこうという本だと思う。

「リファクタリング」の完全読破。その8、7章後半

前回に引き続き、7章の後半。
8月に読み終わる予定が、もう10月も中旬に。

委譲の隠蔽(P157)

カプセル化は、唯一のとは言わないまでも、オブジェクト指向技術の鍵である。

class Client... 
  //before
  _manager = john.getDepartment().getManager();
  //after
  _manager = john.getManager();  }


class Person{
  Department _department;
  public void setDepartment(Department arg){
    _department = arg;
  }

  //before
  public Department getDepartment(){
    return _department;
  }
  
  //after  委譲メソッドを作り、getDepartment()は削除する。
  public Person getManager() {
    return _department.getManager();
  }
}

class Department{
  //このクラスはリファクタリング前後で変更なし。
  private Person _manager;
  public Department(Person manager){
    _manager = manager;
  }
  public Person getManager(){
    return _manager;
  }
}

仲介人の除去(P160)

委譲の隠蔽の逆。
隠蔽をどの程度施すのか見極めるのは困難で、システムが変化すればその基準も変化していく。
適当だったカプセル化もしばらくすると扱いにくくなるが、それは悪いことではない。ひたすら直すこと。

外部メソッドの導入(P162)

「利用中のサーバクラスにメソッドを追加する必要があるが、そのクラスを変更できない」場合に行う。

約束は二つ。
作成するメソッドの第一引数は、サーバクラスのインスタンスとする。
決まったコメントをつける。（//外部メソッド；<サーバ名>クラスにあるべき）

コードの例が古すぎてEclipseが全力で取り消し線をつけてくれるんだけど、ここはDateクラスほどいい例が他に浮かばないのでそのまま写経してみた。
当時のDateクラスは、どこのシステムでも自社フレームワークとして拡張してるんじゃないかな。

Date newStart = new Date(previousEnd.getYear(), previousEnd.getMonth(), previousEnd.getDate() + 1);
↓
Date newStart = nextDay(previousEnd);
private static Date nextDay(Date arg) {
//外部メソッド；Dateクラスにあるべき
  return new Date(arg.getYear(), arg.getMonth(), arg.getDate() + 1);
}

局所的拡張の導入(P164)

外部メソッドの導入は対象メソッドが2つまで、こちらは3つ以上のときに行う。
サブクラスかラッパーか、どちらでも採用できるが、ファウラーは可能ならば作業の少ないサブクラス化を勧めている。
新クラスには元のオブジェクトを引数とする変換用コンストラクタを作る。サブクラスにしたならsuperで、ラッパーなら委譲フィールドを設定する。
以下はサブクラスの場合の手順で、ラッパーの場合については割愛する。

Date newStart = new Date(previousEnd.getYear(), previousEnd.getMonth(), previousEnd.getDate() + 1);
↓
Date newStart = new MfDate(previousEnd).nextDay();
public class MfDate extends Date{
  public MfDate(String dateString) {
    super(dateString);
  }
  public MfDate(Date arg) {
    super(arg.getTime());
  }
  Date nextDay() {
    return new Date(getYear(), getMonth(), getDate() + 1);
  }
}

次回は8章だけど、先は長い。

「リファクタリング」の完全読破。その7、7章前半

７章は２回に分けて。今回は前半部分について。

第7章　オブジェクト間での特性の移動

オブジェクトの設計において根幹をなすのは責任をどこに配置するか。
しかし、ファウラーでも「責任を初めから正しいところに配置することができません。」と言う。
後からでも、リファクタリングを使って適切に配置していけば良い、ということだ。
それに、システムは変化していくということを忘れてはいけない。

P146　ある週では正しく適正であった設計判断も、次の週にはそうでなくなります。それが問題なのではなく、それについてなにもしないことが問題なのです。

このような状況を受け入れなければならない。
受け入れた上で、下記のような方法で解消していく。

メソッドの移動(P142)

メソッドが、定義しているクラスよりも他のオブジェクトを参照することが多い場合に検討する。
移動することでクラスが単純になり、責任の集合をすっきりした実装に収めることができる。
ただし、サブクラスまたはスーパークラスで利用しているメソッドであり、ポリモーフィズムをまるごと表現できないならば移動してはいけない。
メソッドの移動を行うメソッドへの参照が多い場合は、すべて書き換えるのは困難なので委譲メソッドを残す。
（コード例はフィールドの移動と合わせて後述。）

フィールドの移動(P146)

フィールドが、現在または将来に渡って、定義しているクラスよりも他のクラスから使われることが多いときに行う。
はじめに「フィールドのカプセル化(P206)」、「自己カプセル化フィールド(P171)」を行う。つまりprivateにしてアクセサを作る。
その後、フィールドの移動と参照しているメソッドの修正を行う。

上記二つの例を合わせて示す。
まずは、リファクタリング前のコード。

class Account{
  private AccountType _type    = new AccountType();
  private int _daysOverdrawn = _type.daysOverdrawn;
  //メソッドの移動前
  double overdraftCharge(){
    if(_type.isPremium()){
      double result = 10;
      if(_daysOverdrawn > 7) result += (_daysOverdrawn - 7) * 0.85;
      return result;
    }
    else return _daysOverdrawn * 1.75;
  }
  //フィールドの移動前
  private double _interestRate;
  double interestForAmount_days(double amount, int days){
    return _interestRate * amount * days / 365;
  }
}

class AccountType{
  public int daysOverdrawn;
  public AccountType() {
    daysOverdrawn = 8; //本来はもっと複雑な式
  }
  boolean isPremium(){
    return true; //本来はもっと複雑な式
  }
}

上記のコードをリファクタリングすると、下記のようになる。
なお、このコード例はあくまで手法を示すものであり、リファクタリングを適用する状況の判断は自分自身で行う。
（実際に、ここに書いたコードだけを見ると、私はメリットがあるとは思えない。）

class Account{
  private AccountType _type    = new AccountType();
  private int _daysOverdrawn;
  //メソッドの移動後に委譲にする場合。そうでなければ呼び出し元をすべて修正する。
  double overdraftCharge(){
    return _type.overdraftCharge(_daysOverdrawn);
  }
  //フィールドの移動後、アクセサに変更する。
  double interestForAmount_days(double amount, int days){
    return _type.getInterestRate() * amount * days / 365;
    //利用するメソッドが多い場合は_type.getInterestRate()を返すgetInterestRate()を作るのも良い。
  }
}

class AccountType{
  public int daysOverdrawn;
  public AccountType() {
    daysOverdrawn = 8;
  }
  boolean isPremium(){
    return true;
  }
  //メソッドの移動後
  double overdraftCharge(int daysOverdrawn){
    if(isPremium()){
      double result = 10;
      if(daysOverdrawn > 7) result += (daysOverdrawn - 7) * 0.85;
      return result;
    }
    else return daysOverdrawn * 1.75;
  }
  //フィールドの移動後、アクセサも定義する。
  private double _interestRate;
  double getInterestRate() {
    return _interestRate;
  }
  void setInterestRate(double arg){
    _interestRate = arg;
  }
}

クラスの抽出(P149)

クラスは、きっちり抽象化されたものであり、少数の明確な責任を担うべきである。
しかし、実際にはクラスは成長していくので、大きすぎて理解出来なくなったクラスは切り離す必要がある。
切り離し、元のクラスから新クラスにリンクを貼り（必要があるまで双方向にはしない）、低レベルなメソッドから移動していく。

（切り離したNewClassに対して、元のOriginalClassからリンクを貼る）
class OriginalClass...
  private NewClass _newClass = new NewClass();

クラスの抽出後に考えるのはアクセス制御。
publicは問題が多く、複製してから外部に渡すことも混乱の元になる。
ここでは元クラスを利用することを強制するか、新クラスを不変にするか、新クラスの不変インタフェースを用意する方法が薦められている。
また、最後に「クラスの抽出は、並列プログラムの並列実行可能性を向上するための一般的な技法」とも書かれている。

クラスのインライン化(P154)

クラスの抽出の逆。特に注意は無し。

７章は次回に続く。

「リファクタリング」の完全読破。その6、第6章後半。

前回は「第6章　メソッドの構成」から『総論と「メソッドの抽出(P110) 」「説明用変数の導入(P124)」』について書いたので、今回は残りの項目を。
大きなものは「メソッドオブジェクトによるメソッドの置き換え」くらいで、あとは項目名のとおりという印象。
（※下記のコード片は、本書の例を元に短縮等を行ったもの。）

第6章　メソッドの構成

「メソッドのインライン化(P117)」

不要な間接化、つまり委譲のみ行っているようにみえたら行う。単純な場合にのみ行い、複雑な場合は避ける。

return (moreThanFive()) ? 10 : 0;
boolean moreThanFive(){ return _preAmount > 5; }
↓
return (_preAmount >5) ? 10 : 0;

「一時変数のインライン化(P119)」「問い合わせによる一時変数の置き換え(P120)」

「一時変数のインライン化(P119)」は、よく「問い合わせによる一時変数の置き換え(P120)」の一部として使う。
先に変数をfinalにしてみるのがコツ。エラーがなければ一度しか代入されていないことがわかる。
これらも、一度だけ代入されるか副作用がない場合に行う。
複数回代入されるなら「一時変数の分離(P128) 」、副作用があるなら「問い合わせと更新の分離(P279)」を適用することを考える。

//一時変数のインライン化
double todayPrice = anOrder.getTodayPrice();
return (todayPrice > 1000);
↓
return (anOrder.getTodayPrice() > 1000);

//問い合わせによる一時変数の置き換え
double basePrice = _quantity * _itemPrice;
return basePrice * 3;
↓
return basePrice() *3;
private double basePrice() {
  return nowPrice * quantity;
}

「一時変数の分離(P128)」

複数回代入される一時変数は、代入ごとに別の一時変数に分ける。
複数回設定されるのは、複数の責任を担っていることを示す。 複数の責任を担う変数は、コードを読む人を混乱させる。

double temp = 2 * (_height + _width);
System.out.println(temp);
temp = _height * _width;
↓
final double perimeter = 2 * (_height + _width);
System.out.println(perimeter);
final double area = _height * _width;

「パラメータへの代入の除去(P131)」

int discount(int inputVal)
 if(inputval > 50) inputVal -= 2;
↓
int discount(int inputVal)
  int result = inputval;
  if(inputval > 50) result -= 2;

//代入が悪いだけで、メソッドの使用はなんら悪いことではない。
void aMehod(Object foo)
  foo.modifyInSomeWay(); //OK
  foo.setBar();          //OK
  foo = anotherObject;   //NG

この項目で重要なのは、上記の例よりも ”Javaは、厳密にはすべて値渡しを使っている””本質的に、オブジェクトへの参照は値渡し”ということ。

「メソッドオブジェクトによるメソッドの置き換え(P135)」

メソッドの分解を困難にするのはローカル変数である。Method Objectパターンを使う。
ちょっとこれは大きいので、無意識に出来るようになるまで何度か本書を読み直した方が良さそう。

class Account
 int gamma(int a, int b, int c){
   int value1 = (a * b ) + delta();
   int value2 = (a * c) +100;
   if ( (c - value1) >100 )
     value2 -=20;
   int value3 = value2 *7;
   return value3 - 2 * value1;
 }
↓
class Account
 int gamma(int a, int b, int c){
   return new Gamma(this, a, b, c,).compute();
}

TDDの調子で、抽出したGammaクラスとcomputeメソッドを書く。
これでリファクタリングの対象はGamma.compute()になる。というテクニック。

「アルゴリズムの取り替え(P139)」

文字通り、よりよいアルゴリズムに変更する。項目として必要なのはわかるんだけど、内容はタイトル以上のものでもないので割愛。

以上で第6章は終了。