オブジェクト指向のソースを読むのが難しい理由 - 都元ダイスケ IT-PRESS
ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。 あるクラスについて知りたかったら、まずその基底クラスを知れ 例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基本的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。 さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気
Java: The Good Parts - 都元ダイスケ IT-PRESS
Java: The Good Parts 作者: Jim Waldo,矢野勉,笹井崇司出版社/メーカー: オライリージャパン発売日: 2011/02/24メディア: 大型本購入: 3人 クリック: 148回この商品を含むブログ (37件) を見る 来る2/23、オライリーよりJava: The Good Partsという訳本が発売されます。この本は、監訳のid:t_yanoさんからお話を頂き、査読に参加させて頂いた関係で、献本を頂きました。どうもありがとうございました。 オライリーからは「The Good Parts」シリーズの書籍が何冊か、既に出版済みです。例えばJavaScript: The Good Partsは、（ざっと眺めただけですが）jsにおけるコーディング指針を紹介しているような印象でした。こう書くと良いよ、こう書くと分かりづらくてよくないよ、という感じ。PHP: The G
互換性維持とリファクタリング - 都元ダイスケ IT-PRESS
互換性とは ソフトウェアは、広く使われれば使われる程、互換性が大事になってきます。ここでは、ソフトウェアライブラリ・フレームワーク等の互換性を考えてみまよう。互換性は以下の2つに分けて考えることができるようです。 上位互換性：ライブラリのバージョンを新しくしても、このライブラリに依存したソフトウェア（クライアント）が正しく動くこと 下位互換性：ライブラリのバージョンを古くしても、このライブラリに依存したソフトウェア（クライアント）が正しく動くこと ライブラリ等のバージョンにおいては、古いバージョンに切り替える機会よりも、新しいものに切り替える機会（とモチベーション）の方が多いため、一般的に上位互換性の方が重要視されます。（ただ、Excel等のアプリケーションが吐き出すデータファイルは、下位互換性が求められることも多いです。つまり、Excel2000で作ったデータはExcel97でも読める、
Baseunits Library - 都元ダイスケ IT-PRESS
さて、Java Advent Calendar -ja 2010 : ATND 10日目。昨日は、id:yuroyoro でした。二日連続で真っ黒な魔術が紹介されたので、ここは真っ白で実用的な奴をひとつ。 最近Domain Driven Design（DDD）っていう設計手法が、自分の周辺一部で話題になっている。当然、賛否両論なんだけども*1、個人的には好きな考え方でして。ま、詳細は色々な方がブログに書いているので割愛します。興味あれば本読んでみましょう。洋書*2だけどｗ Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113
UnsupportedOperationExceptionと相続拒否 - 都元ダイスケ IT-PRESS
昨日ご紹介したbaseunitsですが、そのコードを社内コードレビューに掛けた際、id:cobonasからこんな指摘がありました。 package jp.tricreo.baseunits.util; import java.util.Iterator; /** * 明示的に、対象のコレクションに対する操作ができないことを表す反復子。 * * @param <T> 要素の型 */ public abstract class ImmutableIterator<T> implements Iterator<T> { @Override public void remove() { throw new UnsupportedOperationException("sorry, no can do :-("); } } https://github.com/tricreo/baseunits/b
ボク、if文。わるいモンスターじゃないよ！ - 都元ダイスケ IT-PRESS
id:aroundthedistance に召還されたぜ。 http://d.hatena.ne.jp/aroundthedistance/20100727/1280227851 …その昔なー。Seasar Conferenceで「あなたのコードからnewとifが消えます、魔法のDI」みたいなセッションをした。今思い出して「釣りすぎたぜサーセン」という気分になったことをまず懺悔しておく。 この doBusinessん中のif〜else ifをなんとかしたい。 …（中略）… ちょっとすっきりした。けどまだifが残ってるよね。 ポリモーフィズムの例をもうちっと実用的に書いてみた。 - 都元ダイスケ IT-PRESS どんだけif文悪者なんだ。そこまで嫌ならば、一度もif文を書かずにコードを書けばいい。無理だがなｗ と自嘲。 if文に限らず、問題になるのは濫用なのだ。"ある知識"がトッ散らかって
インスタンスを抽象的に扱う - 都元ダイスケ IT-PRESS
まず「抽象的」という言葉が難しいのかな。俺も最初の頃、一体何なのかわからなかった。プログラムに全く縁もゆかりも無い相方に、オブジェクト指向の話をすこしだけ聞かせたことがあって、「抽象的って、要は大ざっぱってこと？」と問われた。なるほど、良い表現だ。 「Android携帯HT-03A」というオブジェクトがあったとする。それを大ざっぱに扱う（いや、別に物理的に雑に扱う訳ではなく）とはどういうことか。結論を言えば、「文脈上、細かい事を気にしなくて良い場合は、細かい事を記述しないこと」だ。 Android携帯として扱う → HT-03Aではなく、DesireやNexusOneで良い場合は、HT-03Aである、という限定をしない 携帯電話として扱う → Android携帯ではなく、ガラケーでも良い場合は、そういう限定をしない 電子機器として扱う → そもそも携帯の話じゃなくて、電子機器の話という文脈
イリュージョニストにならないために - 都元ダイスケ IT-PRESS
前回は「クライアントにとって使いやすいAPI」について語りました。今回は「読みやすい実装」について。ネタ元は同じくSqlExecutor。 まず。javadoc厨で契約（仕様）原理主義の立場でいきなり厳しいことを言ってしまえば、「そもそもクライアントに実装を読ますなよ。javadocで全部伝わるように書け。」ってことになるのだが、まぁまぁ、そこまでスパルタンにはなるまい。 でだ。何か追いかけたい事があって、メソッドの実装を追いかけ始めた。そして、以下のようなコードに出会ったとする。 java.sql.Statement stmt = ...; java.sql.ResultSet rs = ...; ResultHandler handler = ...; String sql = ...; if (stmt.execute(sql)) { rs = stmt.getResultSet()
クラスがメソッドの実行に必要なインスタンスを手に入れる方法色々 - 都元ダイスケ IT-PRESS
あるクラスが、メソッドによってある役割を果たすためには、別のインスタンスが必要なことが多い。ここでは、具体的にそのクラスを考え、そのインスタンスのを手に入れる方法を比較していこう。 ここでは、あるクラスをSqlExecutorとしよう。SQL文を受け取って、データベースのConnectionを使って実行するクラスだ。そして、SQL実行結果(ResultSet)をResultHandlerに渡して処理をする。さて、このクラスが責務を果たすためには「SQL文」「データベースConnection」「ハンドラ」の3つのインスタンスが必要だ。このクラスをいくつか書いて、比較してみよう。 どのインスタンスを、どのように受け取るかの違いだ。各インスタンスに対して、「setterで受け取る方法」「コンストラクタで受け取る方法」「メソッド引数で受け取る方法」がある。 A.全てsetterで受け取る方法 im
hamcrestのMatcherメモ - 都元ダイスケ IT-PRESS
技術ネタじゃないところで盛り上げてしまった。技術ネタいこう、技術ネタ。 さて、JUnitを使う際、hamcrestライブラリを使って、英語として読めるようなassertionを書く、なんてのは流行ってたり流行っていなかったり？ JUnit4限定だけれど、assertionの際、assertEqualsとか色々assertionのメソッドはあるけど、全てassertThatで書くことができるはず。assertThatメソッドの第一引数にテスト対象、第二引数にhamcrestのMatcherインターフェイスの実装を与えます。なんのこっちゃですが。 Jiemamyでは、なるべくassertThat以外のassertionメソッドを使わないようにテストを書いています。（もしかしたらもう一つも残ってないかも。） まぁ、以下のように書くと、英語っぽいのが書けますよ、と。 assertThat(aaaa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
