今回で最後。
60点どうのこうのいうよりも、Javaがわかってないし経験も足りないので、がんがん書いていって自分のスタイルをつかんでいくのがよいんじゃないか、という結論になりつつある。
でもね、こういう悩むって過程も必要だと思うのだ。悩まざる者、そこにあるのは死だ！みたいなことを、妖精王(山岸凉子)で言ってたように思うが、そんな感じ。
それに、ときどき立ち止まって振り返らないと。
技術なんてしばしば新しくなるから、自分がその時知っていた最善の技術が、今ではそうでもないこともあろう。
ほら、今見てるチェック例外だって、時代を経るに従って受け止められ方が違ってきてるみたいだし。
そういう変化があるから、技術はいつも新鮮で、そういうのが好きな人達をつかんで離さないのだと思う。
というのもあるが、私が飽きてきた、というのが一番の理由だ。
あっさりと終わらせてしまいたかったのだが、どうしてもわからないところがあった。
これだ。
BasicTagTechnology(Tag tag, int tech) throws RemoteException {
mTag = tag;
mSelectedTechnology = tech;
}
Javaって、Operator Overloadはなかったはず。
つまりここで行われるのは、純粋な代入処理。
なぜ、RemoteExceptionのチェック例外が指定されているんだろう？
まず、コンストラクタでも例外は返してよさそうだ。
根拠って言う根拠は見つけてないけど、C++でもコンストラクタで返せるから、くらいか。いや、言語も思想も違うのはわかるんだけど、なんか、イメージとしてね。
BasicTagTechnologyクラスはabstractだから、継承する方もthrowsまで@Overrideしないといけないのかもしれない。
つまり、基底クラスにthrowsがついていなかったら、派生クラスにも付けられない、という考え方だ。
どうだ？
ってよりも、私がちょろっとやったとき(Personal Java)のときは、@Overrideなんてなかったぞ。
まあ、そんなことをいったら、私が入社した頃のコンパイラはCにvoidポインタがなかったけどな。
あ、@Overrideは不安なので確認しておこう。
onCreate()にthrows IOExceptionを追加すると・・・エラーが出た。
エディタ上に出たので、コンパイルエラーなのかどうかがわかってないけど、ダメだと思ってよいのだろう。
つまり、BasicTagTechnologyのコンストラクタでthrowsを付けたのは、「きっと子供たちの誰かがRemoteExceptionを返したくなることがあるはず・・・」という親の想いがあったからだろう。
それをありがたいと思うか迷惑と思うかは人それぞれだろうが、その子供たちもthrowsというくびきを背負うことになるのだな("くびき"って、頸と木で、十字架の意味？)。
で、疲れてきたので、しばらくこうしようと思う。
- 標準で実行時例外があるものは、知ってる範囲でそれを返すようにしよう。
それをcatchするのは、引数に責任を持っている人。
たとえば、A-->B-->Cの順番で呼ぶことになっていて、Aは引数無し、Bが引数付き、Cが引数で例外発生、となったら、Bがcatchする。
Bが作った引数にAが関与しているなら、Bがcatchして意味を持つExceptionに変換してAに投げる。
- チェック例外は、継承した人達が使いそうなら、とりあえず付けておく。
そこまで先がわからないなら、付けない。
チェック例外を受けた方は、なるべく早めに他の例外なり戻り値なりに変換した方がよい。チェック例外はけっこうどうしようもない例外が多いので、上に行けば行くほど「なんのこと？」になってしまうと思うから。
かなり曖昧なところは残るのだけど、とりあえず文章にすることができたのがよかった。
仕様書はいらん、となることもあるかもしれんが、文章で説明できないことを口頭で説明できるとも思えない。
文章で説明して、足りないところは口頭で説明して、ダメなら会って説明して、その結果をまた文書に反映して、というのを繰り返して、ようやくできあがるものもある。
ネットの時代だ、とかで大規模開発が時代遅れっぽく見られることもあるけど、やはり工数がかかって、人数も多く必要で、という開発は存在するだろう(そういう開発しかやったことがないけど、ネットに出ないだけだと思う)。
工数がかかって人数が少なめでよい場合はいいんだけど、だいたいそういうときは「金に糸目は(あまり)つけないから、ばんばん人使って開発しろー」ってときだと思う。
そうなると、人－人の意識伝達を早くするため、プロジェクトの最初の方で「こうやりましょう、こんな感じでやりましょう」という大きな方向付けがあるだろう。
100人すごい技術者をそろえても、各人が1時間まごまごしたら、100時間無駄になるのだ。その「まごまご」は、各人のせいではなく、管理者の責任になる。
そうなると困るので、まずは100人が直接自分と対応するのではなく、グループを作ってもらい、そのグループ長とだけ接点を持つように考える。そうすると、まごまごの責任は分散できる(ということより、100人の相手はやってられない、という物理的な事情があるのだが)。
そうして、この責任を・・・
はっ、なんか、関係ないことまで書こうとしてる！！
ともかくここで言いたかったのは、例外処理について考えるだけでもこういうごにょごにょした議論を一人ですることになるんだから、お仕事で人に来てもらって作業するときは、そういう議論があることを前もって把握して、準備しておくべきだろう。
私は一人でJavaやっているので、基準作りは自分でやらないといけない。
そして、自分の書いたJavaのコードに、それぞれそれなりの説明を付けられるようになったとき、私も「初級Javaプログラマ」の称号を得ることができるのであろう！
まだ見ぬ、その日まで・・・。