ダラダラ書かない予定だよ。ざっくり行くよ。あと、分かってる人には当たり前な事だと思うよ。 あるクラスについて知りたかったら、まずその基底クラスを知れ 例えば、Integerクラスについて知りたいと思ったら、Integer.java だけを読んでいてはダメだ。確かに「Integerに特化した責務・構造・操作」は読み取れるかもしれないが、数値としての基本的な責務・構造・操作はNumberに書かれている。それを読まずして、Integerが保つ数値という一面を知ることはできない。Integer.javaには「Integer - Number」*1の情報しか書いてないのだよ。差分プログラミング。 さらに、忘れちゃいけない。Object.javaを読め。全ての道は暗黙的にObjectにつながっている。Objectを知らずしてJavaのクラスを知る事は絶対にできない。Objectなんて、みんな「知った気

今日はインピーダンスミスマッチについて語ってみたいと思うのだが、そもそもインピーダンスって何よという所を説明しなければなるまい。 前半、オブジェクト指向には全然関係ない話に見えると思うが、少々辛抱いただきたいｗ オームの法則 私が初めて「インピーダンス」という言葉を聞いたのは、大学の軽音楽部（要は、バンド部だ）に所属して、音響理論まわりを勉強している時だった。スピーカーや、マイク等の電子音響機器の入出力端子には、インピーダンスという値（単位はオーム）が示されている*1。 学生時代、オームの法則でつまずいた人は多いと思う。おそらく、未だによくわからない人が大半を占めるだろう。E=IR、電圧＝電流×抵抗って奴だ。 なんで理解できないのかって、「電流・電圧・抵抗って一体なによ」というイメージが全くできないからだと思う。抵抗はおぼろげながら「電気を流れにくくする何かやな」ってのは分かるかもしれない

java.io.Serializable …、ある程度Javaに触れて来た人は必ず見たことがあるインターフェイスだと思う。私も何度も見てきたし、必要に迫られて自分の作ったクラスにSerializableをつけたこともある。しかし、こいつは一体何なのか？ 継承の便利さ 僕らがまだJava初心者だった頃。継承というメカニズムに助けられながら育って来た。簡単に言えば、HttpServletクラスを継承しさえすれば、自分の作ったクラスがサーブレットとして認識されるのだ。また、abstractメソッドなどという便利な機能もあり、継承にあたって実装しなければいけないメソッドは確実に指示され、言われた通りにそのメソッドを実装すれば良い。 StrutsのActionも然り。そう、多くの場合は「継承さえすれば、望む物がだいたい出来上がる」というのがJavaの世界だと思っていた。 だが、世の中そんなに甘くない

いやー、なんか怖い人（笑）が見てるようだ。突っ込み激しそうぜよｗ さて、前回言っていた「判断ロジック」についての答えは各自考えてみただろうか？ 各方面の反応を見ると「1〜4どれでしょうか*1」という問いにすり替わっちゃってる気がするけど、テーマは「1〜4を決めるロジックを考えてください」なんだ。書き方悪かったもしれんｗ まぁつまり、昨日のエントリの時点では1〜4どれでもないのですよ。判断ロジックがないので。 というわけで本題。アプリケーションレベルでのバグとは「実際の挙動が仕様と違うとき」ですね。挙動があるべき姿(=仕様)と違う時にそいつバグとするのが妥当です。そしてそれはコードレベルでも同じ基準で良いんじゃないでしょうか。 じゃあ、仕様とは何か。Javadocコメントですよ。Javadocがないとバグの定義さえもできないんです。だから口酸っぱくJavadoc書けとｗ*2 まぁつまり「Ja

これから書くことは決して「これをしなければいけない」とか「他に手段はない」なんてコトを主張したいのではない。色んな道があるはずだぁ。その中の一つの事例として、自分がやってきたことをフレームワーク化し、色々挙げてみようと思う。 当然、俺の主観が入りまくっているので、突っ込みどころは満載だろうなｗ そもそも「エンジニア」って何？ｗ その辺り、はてブ界隈のミナサマにおかれましてはお手柔らかに願いたいｗｗ さて、いきなりどこかの技術系カンファレンスで1時間喋っちゃえ、とか突然は無理なのは分かる。何を話せばいいのやら、どこに喋るチャンスがあるのやらだ。しかし、そういう所で喋るような自分を将来のビジョンとして持っている人は、以下に挙げることを小さなことからコツコツと実践してみるといいかもしれない。という意図で書いていく。 何事にも興味を持とう 興味は勉強の原動力。興味のない勉強は苦痛でしかない。ここが

1st Seasonはこちら。Throwableについて本気出して考えてみた - 都元ダイスケ IT-PRESS 以前は、何かをスローする状況を3つに分けてそれに合った設計をした例外を投げましょう、という考え方を示しました。 callerのバグ: RTE calleeのバグ: Error どちらでもない: Exception (非RTE) まぁ詳しくはSeason1の方で。 Seasar2はRuntimeExceptionですね。2004年ぐらいからのフレームワークはRTEをスローしていると思いますよって、ひがさんから情報。 チェックされる例外とチェックされない例外について - じゅんいち☆かとうの技術日誌 ただ、上記のような考え方もあるのも事実。実際.NETやRuby, Python, 新鋭のScala等もcatchを強制する例外というものが言語仕様的に存在しません*1。逆に、チェック例

ということで、現状のコンポーネントをリストアップして、概要を日本語（一部英語のままｗ）でまとめてみました。今後、個人的に興味のあるものを順にピックアップして、もう少し深く知っておく、という作業をしてみようかな、と思ってます。 まずは、commons-langを掘ってみている。すげええええええの連続です。近々ご紹介しますとも。 Properシリーズ（正式プロジェクト） コンポーネント mvn 説明 参考 attributes ○ メタデータ属性（docletタグ等）ランタイムAPI。javadoc内アノテーションを処理する。Java4以前で有用かも。 参考 beanutils ○ Reflection/Introspection APIのラッパー 123 betwixt ○ JavaBeans・XML間の相互マッピングAPI 参考 chain ○ "Chain of Responsibili