2006-05-07 [長年日記]
■Javaで引っかかるところ
Javaならインタフェース？インナークラス？ジェネリクス？
結城浩のはてな日記 - プログラミング言語で引っかかるところ
「インナークラス」じゃなくて、「ネストされたクラス全般」に一票。
内部クラス(inner class)、メンバクラス(member class)、静的なネストクラス、無名インナークラス(anonymous inner classe)などなど。
new java.awt.event.ActionListener a =
new java.awt.event.ActionListener() {
public void actionPerformed(ActionEvent e) {
...
}
};
とか。
なんで interface に new が付くの!? と初めに見たときは思ったものです。
■ネット詐欺
今日、漫画喫茶で、
- 作者: 黒丸,夏原 武
- 出版社/メーカー: 小学館
- 発売: 2005-10-05
- ASIN: 4091531474
- メディア: コミック
を読んできたところ。
これは是非引用したい。手許に置きたいということで買ってきた。
ネット詐欺、というサブタイトルで5話連続で掲載している。
理由もなく"インターネット怖い"と思っている方には、いい読み物だとは思った。
が、なんか表面をなぞっただけ、という印象。
一応作品の紹介をしないと話が続けられないか。
主人公は詐欺師。ただし、詐欺師だけを相手にする詐欺師だ。過去に父親が詐欺にあって心中を図り、主人公独りだけ生き残った、という主人公の動機付けがある。主人公はクロサギと称され、彼の詐欺の相手――つまり"普通の"詐欺師はシロサギと称されている。
この「ネット詐欺」のシリーズで、これじゃ駄目だ! と思わせる点が一つ。
シロサギがバカにしか――あるいはコンピュータ素人にしか見えない、ということ。
フィッシング詐欺用に、偽サイトを作る。ウィンドウを2つ並べているモニタ。
「どうです? 右が本物のひまわり銀行のサイト、左が俺が作った偽サイトです。」
「見事なもんだな。どこから見ても、本物だ。」
いや、それ全然「見事」じゃないし。それだけなら誰でもできるじゃん。
フィッシング詐欺のキモは、「本物そっくりな偽サイトを作る」ところじゃなくて「偽サイトに如何にして誘導し、そして気付かせないか」だ。「本物そっくりな偽サイトを作る」だけなら、あっというまにできるだろう。
名簿屋から名簿を買い付けるシロサギ。
圧縮し、メールで送られる名簿(この時点ですでに非常に間抜けっぽいが)。
解凍するとでてくる3つのフォルダ。
だが3つめのフォルダはクリックしても開かない。
「フォルダが壊れてるのかもしれませんね……
エラーは出ませんけど。」
「あとで児玉(引用者註:名簿屋の名前)に文句言ってやる。とりあえず名簿は保存しておけ。」
ハァ? それだけ? それでいいのか!?
……
で、案の定その3つ目のフォルダはトロイであるわけだが……、
「あの、ウイルスメールが効いてくるわけだ……!」
「"Phaming"――か」
「そう……あのウイルスはパソコンに感染すると、パソコン内のhostsファイルの内容を書き換えるように作られてる。」
それ、ウイルス?
感染したっていうの?
ていうかhostsファイル書き換えって……(脱力)。
いや、まぁいいんだけどね。主人公はシロサギの上を行かなければならず、そのためにはシロサギはある程度間抜けに描かれる必要があるわけで。
この巻を読んで、
で書いた「偽の発信者電話番号を送りつけて電話する」というのがどういうことか判ったのは良かった。
なんて書いていたら、
こんな内容のプログラムは.exe形式で作成する必然性は全くなく、Web上で安全性が保証されたプログラム（JavaScriptや、Javaアプレットや、Flashコンテンツや、サーバサイドのプログラム）で実現できるのであり、できるだけそうした方法でプログラムを提供するというのが、近代的なソフトウェア配布のあるべき姿とされつつあるところ、それをITmediaがブチ壊した。
高木浩光＠自宅の日記 - Greasemonkey利用者の感覚と不正指令電磁的記録作成罪立法者の感覚
高田さんがこう書かれていていて「本当にね」と思った次第。
■package で引っかかったこと
何かの雑誌で読んだのだと思うけど、もう思い出せないし正確な引用もままならない。
でも、もう"やっちまった"後だったので、"そう。本当にその通りなんだよなぁ"と思いながら読んだこと。
業務のサブシステムと、Java の package は違う概念だ。一緒にしてはいけない。
つまり、package を業務のサブシステムごとに分割してはいけない。
"してはいけない"という調子だったか、"するべきではない"ぐらいだったか、そのへんのニュアンスは思い出せない。
何の断わりもなくサブシステムと書いているが、まぁ、10年ぐらい前にSEになった私が配属当時あたりまえに聞いていた言葉である。生産管理のシステムなら、生産計画，在庫管理，作業工程管理，受注・出荷管理あたりがサブシステムか。
サブシステムごとに package を作ることになったのだけど、特に異議を唱えずに進んでいって、後から後悔した、と。まぁそういう経験があったので、くだんの雑誌を読んだ時に"その通りだなぁ"と思ったのだ。
なんでこんなことを書こうと思ったかというと、
サブシステム間でクラスを共有する場合、相手のサブシステムに公開したくないクラスは必然的に同一パッケージに入れる必要があり、管理が難しくなると思いますが、実際現場ではどのようにされているのでしょうか。
人力検索はてな - Javaのメソッドにおけるアクセス修飾子は、 同一クラス内である(private)か否か パッケージプライベートである(なし,protected)か否か サブクラスである(protected)か否か..
てな質問を見かけたから。
■あれ?
今気がついたのだけど、昨日の日付で追記していたのか。
トラックバックしたのもあるし移動はしないでおこう。