「リファクタリング」の完全読破。その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()は
「リファクタリング」の完全読破。その6、第6章後半。 - 南極の図書館
前回は「第6章 メソッドの構成」から『総論と「メソッドの抽出(P110) 」「説明用変数の導入(P124)」』について書いたので、今回は残りの項目を。 大きなものは「メソッドオブジェクトによるメソッドの置き換え」くらいで、あとは項目名のとおりという印象。 （※下記のコード片は、本書の例を元に短縮等を行ったもの。） 第6章 メソッドの構成 「メソッドのインライン化(P117)」 不要な間接化、つまり委譲のみ行っているようにみえたら行う。単純な場合にのみ行い、複雑な場合は避ける。 return (moreThanFive()) ? 10 : 0; boolean moreThanFive(){ return _preAmount > 5; } ↓ return (_preAmount >5) ? 10 : 0; 「一時変数のインライン化(P119)」「問い合わせによる一時変数の置き換え(P12
「リファクタリング」の完全読破。その5 - 南極の図書館
今回からカタログに入る。第6章は内容が多いので2回にわけて。 今回は、総論と「メソッドの抽出(P110) 」「説明用変数の導入(P124)」をしっかりと。 第6章 メソッドの構成 総論 下記の通り重要な章。いくつかの項目を除けばクラス階層の変更が不要なので、やりやすいという面もある。 （経験上、クラスを作ったり消したりすると面倒になる職場が多い。悲しいことに。） P109 メソッドを、適切にパッケージ化されたコードとして構成することが、本書のリファクタリングの大部分です。 問題を起こすのは、ほとんどの場合、長すぎるメソッドなのです。 メソッドを分解すると、その動作がより深く理解できます。そして、そのアルゴリズムがもっとわかりやすくできることに気づくかもしれません。 さて、いったいどこまでメソッドを小さくするといいのだろうか。 私はここに書いてある通りと考える。 P110 メソッド名とメソッ
「リファクタリング」の完全読破。その4 - 南極の図書館
今回は第4章と第5章。この次から、いよいよカタログに入る。 第4章 テストの構築 多分ここが、古いということで一番割を食ってる箇所。 JUnitの説明などは、今は他の本を読んだ良いと思う。 所々出てくる、今読んでも色褪せないなと思う部分だけ引用する。 （古い古いと書いているが、未だにJUnitすら使っていないシステム開発現場はあるし、むしろ経験上そっちの方が多い。） P89 リファクタリングに限らず、よいテストを書くとプログラミングが加速するようです。 P90 テストを完全に自動化して、その結果もテストにチェックさせること。 P94 テストを頻繁に実行せよ。コンパイル時にはテストを局所化して、1日に最低1度はすべてのテストを実行せよ。 P97 バグレポートを受け取ったら、まずそのバグを明らかにするための単体テストを書け。 P98 不完全なテストでも、書いて実行するほうが、実行できない完全な
「リファクタリング」の完全読破。その3 - 南極の図書館
帰省などで間があきましたが、今回は第3章。8月中の読破を目標に。 第3章「コードの不吉な匂い」 テーマは、いつリファクタリングを始めていつ終えるか。 (P76) ここではリファクタリングの必要を示す不吉な兆候について説明していきます。 インスタンス変数はいくつ以上になれば多過ぎであり、メソッドは何行以上で長過ぎるかなどの感覚は、自ら養っていかねばなりません。 他に「経験で磨かれた人間の直感には、メトリックスをいくら集めてもかなわない」とも書かれており、経験の重要さが強調されている。 各項目はそれぞれ半ページから2ページで文量は少ないが、引用されている手法を確認しながら読むとかなり時間がかかる。 本エントリは後から見直せるように、見出しと簡単な説明を書いていく。 重複したコード 同一クラス内の複数メソッドに同じ式がある場合。 完全に同じでなく似通っている場合は、共通に使える部分とそうでない部
「リファクタリング」の完全読破。その2 - 南極の図書館
ソフトウェアシステムはほぼ間違いなく、汚く滅茶苦茶になってしまうことに気づいたからです。 最初はプログラマの心のなかでけがれのない水晶のように輝いていた設計が、時間が経つことで劣化し、悪くなった肉のように腐敗していきます。 1年前に構築した、こぢんまりした出来の良いシステムが、翌年には関数や変数が絡まり合ったひどい泥沼に変わります。 いったい何が起きているのでしょう。 「レガシーコード改善ガイド」まえがき 大きなシステムに携わったことがあるなら、痛いほど気持ちがわかると思う。 私はこの問題を、プログラマのレベルが低いプロジェクトにのみ起こる現象だと思っていたが、どうやらそうではないらしい。 そんな簡単な問題では無かった。 第2章 リファクタリングの原則 ここではリファクタリングの定義にはじまり、行う理由、いつ行うべきか、などが示される。 中でも、私はこの文が気に入っている。これは冒頭の問題
「リファクタリング」の完全読破。その1 - 南極の図書館
ファウラーの言わずと知れた名著だけど、私は15章構成のうちカタログ部分（第5章〜第12章）を今まで読んでいなかった。 理由としては、やはり古いこと、そんなに難しい内容では無いこと、リファクタリングの思想という意味では理解していたこと。 ホントに古い本なので、もういいかなと思っていたんだけど、少し読み直したらやっぱり一度は全部書くべきだった。 リファクタリングの思想と同じくらい、カタログにある各種技術は重要だった。 それに「おすすめの本は？」と聞かれたときに、とりあえずこれを挙げることは多くて、そのくせ完読してないのは質が悪いというのもある。 ということで、今回は「はじめに」と「第1章」 はじめに ここでは本書の説明と、リファクタリングについての話が少し。 ・リファクタリングはリスクが高いのでやみくもに行ってはいけないこと。 ・手順を守り、体系的に行うこと。 ・具体的には「1度に1ステップず
自己流オブジェクト指向プログラミング＆Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂．*1基本的に改訂版への差し替えと一部の新刊の追加程度になっている． お奨めのJava＆オブジェクト指向プログラミング関連の書籍／参考文献リスト．初心者向け入門書や参考書から上級者向けの専門書まで，オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている． 初心者向け勉強の手引き：http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と，あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな．ただしリフ
エンタープライジーなREST - L'eclat des jours(2010-08-10)
_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ
Effective Java 読書会 1 日目「static メソッドの使い方などなど」 - IT戦記
はじめに 社内で「Effective Java を 20 日で読もう」という勉強会が企画されて、今日がその一日目。 ノリノリな感じで。 どーん 今日読んだところ 5 ページ 〜 19 ページ という訳で いろいろ出た話題を残しておく 毎日続けるために、なるべく適当に書いていこうと思う あと、自分が勝手に解釈してる部分も多々あると思うます＞＜ static ファクトリーメソッド static ファクトリーメソッドとは、コンストラクタの代わりに使われる static メソッドのことらしい。 コンストラクタは、名無し たしかに String コンストラクタとかごちゃごちゃしてて一個一個名前付けたほうがいいんじゃね？と思うなーと http://java.sun.com/javase/6/docs/api/java/lang/String.html#constructor_summary Strin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
404