サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
java-etc.cocolog-nifty.com
テストコードを書きながら開発することでバグの発生低下と生産性の増大が見込める ということだが、かなり怪しい。 1.テストコードの対象はメソッド・関数の単位であること。 それらのメソッドが複数使われるアルゴリズム全体の流れの検証はできない。 しかしこれが仕様を満たしているかどうかの最も大切なテストとなる。 この最も大切なテストについては完全に沈黙しているように見える。 2.オブジェクトの状態を制御するようなメソッドの検証の困難性 単に入力と出力があるメソッドならばテストコードを書くことは可能だろう。 しかし複数のメソッドで制御されるオブジェクトを触るようなメソッドを 検証するようなテストコードは難しいだろう。 しかもそのようなメソッドは決して珍しいものではない。 3.テストコードの複雑さについての対処法がない 複雑なメソッドのためのテストコードは複雑になるだろう。 その場合のテストコードが正
WebアプリケーションにおけるMVCパターンはすでに死んでいる。 ページが静的なHTMLから動的なJavaScriptを使用したページになり 状態を保持するようになった時点でMVCパターンは崩壊したのだ。 しかもそれはAjaxを使用することで余計に加速された。 Ajaxを多用するということはページが単なるViewではなく、 オブジェクトになったことを意味する。 サーバー側にもモデルというオブジェクトがあるのだから、 結局はオブジェクト同士の相互作用というのが実態に近い。 MVCとは一つのオブジェクトを3つの部分に分割するというパターンである。 複数のオブジェクト同士の関係については何も言っていない。 このオブジェクト同士の相互作用のパターンというのが現時点でも 未解決のデザイン問題として残っている。 これはかなり複雑な領域であり、容易にモデル化を許さない。 しかも相互に参照しているのではな
たかがSQLと思っていた。 しかし実際に作り始めてみると、されどSQLであった。 何か言いたいのかというと、SQLのSELECTを極める者はSQLを極めるということである。 単純なSQLならば問題ない。しかし複雑なSQL、特に最も必要性が高いであろう複雑なSELECT文は舐められない。 SELECTを極めることはSQLを極めることに直結する。 SELECTの深さこそがSQLの深さでもある。 SQLが興味深いのはそれが集合の理論を基にした言語であるという特徴である。 SQLの魔術、と大げさに言っているが、集合のモデルを基にした思考過程はJavaなどのC言語系の言語からみると魔術に見えるだろうということ。 ・SELECTで難しい点 SELECTで難しい点を挙げると、 1.取得範囲の設定 2.取得結果の編集 この2点がSELECTで難しい点である。 特に難しいのは1の方だろう。 ・SELECTの
ちょっと前までは、mainメソッドが最初に実行され、そのmainメソッド内で実行されている他のクラスのメソッドが次に実行され、というように、メソッドの階層がすなわち実行順序だと思っていた。 しかしこれは間違いだったのである。 実は、メソッドが実行される前に、フィールドが初期化されることが分かった。 これは重大な違いだった。 というのは、もしメソッドよりもフィールドの初期化が先に走るのならば、そのフィールドで実行されているメソッドがmainメソッドよりも先に実行されることを意味しているからだ。 そして実際に試してみた結果、やはりそうだった。 つまり、メソッドの階層だけを見ても正確なシーケンスは追えないということだ。 普通、フィールドの初期化とはフィールドに値を代入するのが目的なのだから、そんな本格的な処理は行われるはずがない、という先入観がある。 しかし、たとえば、int型のフィールドの代入
そうか。やはりgenericsの機能追加は失敗だったか。 以下のサイトで言われているのでやはりと確信してしまった。 http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java 私の主張はシンプルです。Javaは極めて有効に機能していますが、それは80対20の法則にあたっているからです。私の考えでは、今までで最もわかりや すい80対20の技術の勝利一つです。次の20%を埋めようという試みは、たいてい害の無いものでした。ジェネリクスまでは。ジェネリクスは大失敗でし た。 Javaの習得や理解は難しくなりましたが、それを避けることはできないのです。 http://d.hatena.ne.jp/Kazzz/20071225/p1 ワイルドカードは、JavaのGenericsのワイルドカード(?記号)のことを指してるのだ
以前、Sring型のオブジェクトは作成後に状態が変化することはない、という話を書いた。 このようなオブジェクトのことをイミュータブルオブジェクトというらしい。 イミュータブルとは、不変という意味。つまり不変オブジェクトという意味。 このようなオブジェクトは、生成時にコンストラクタに初期値を渡すことで生成される。 生成されたオブジェクトの状態を変更することはできない。 以下引用: http://www.javaworld.jp/beginners/-/36241.html しかし、クラスStringは、「イミュータブル(immutable:不変)オブジェクト」を生成するクラスなので、オブジェクトの状態を変更するメソッドがありません。この点には注意が必要です。 もし生成後の状態を変えたいという場合、Stringではなく、StringBufferを使う必要がある。 なぜ非常に良く使われるStri
・String型オブジェクトの場合、equalsでの比較より、==の方がパフォーマンスが高い 以前、オブジェクトの比較について、== と equalsメソッドの違いについて記事にしたことがある。そこで明らかになったのは、== はオブジェクトの場所の比較、equalsはオブジェクトの内容の比較、という違いだった。 さて、通常のプログラミングにおいて、最も頻繁にオブジェクトの比較が行われるのは、String型のオブジェクトだろう。 そのとき、大抵は、equalsメソッドを使用して比較が行われる。(コーディング規約でそう規定されている職場も多い) Stringオブジェクトの比較は、その内容が等しいかどうかの判定を目的としたものがほとんとである。そうであるがゆえにequalsメソッドの使用が規約とされている。 これはオブジェクトの比較におけるルールに照らしてみると、正しい規約にみえる。 もし ==
それは企業にとってドキュメントはやはりその程度の価値しかないからだ。 プログラムと違って動作検証もできないし、 バイナリだから世代管理をしても差分が分からない。 だからドキュメントの世代管理をしない。 だからドキュメントが更新されなくなる。 そしてそれらは信用できなくなる。 そして必然的に稼動しているソースコードがドキュメントの代わりになる。 またドキュメントの世代管理システムを入れてしまうと、余剰人員が 判明してしまうというのも企業(特に日本企業)にとっては痛いだろう。 世代管理を始めると余計なドキュメントは作られなくなり、結果として 本当に必要な仕事がだんだんと明らかになってくる。 すると余計な仕事で食ってきた中高年層の仕事が無くなる危険性がある。 また余計なドキュメントを作ることで無駄な仕事を作るというSEの十八番が できなくなるのも辛い。 開発をしない生粋のSEにとってはドキュメン
●スレッドセーフ スレッドセーフとは、複数のスレッドが実行されるプログラムにおいて、データの整合性が保障されていることをいう。この場合のデータとは、クラスのフィールドの状態を指す。状態を持たないフィールド( final属性の基本型、final属性のイミュータブルオブジェクト )は更新されないので整合性を気にする必要はない。 staticメソッドとスレッドセーフかどうかは関係ない。 あるメソッドがstaticか非staticかはそのメソッドがスレッドセーフであるかどうかの判断基準にはならない。それらは互いに独立した概念である。 あるメソッドがスレッドセーフかどうかの基準は、以下の基準によっている。 #そのメソッド内で、あるクラスのフィールドの状態を更新しているかどうか もし、そのメソッド内で上記の操作が行われている場合、synchronized 修飾子をつけるべきである。こうすることで、その
このページを最初にブックマークしてみませんか?
『java-etc.cocolog-nifty.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く