SWE619ふりかえり

SWE619のタイトル「OO Software Specification and Construction」に含まれる”Specification"という言葉が暗示するように、このコースでは、他人に使われることが前提のソフトウェアモジュールをどのように作ればよいか、を学びました。

おかげさまで成績は「A+」でした。成績の内訳は、宿題33%、クイズ33%、期末試験34%で、宿題およびクイズは満点でしたし（そのつど結果は返されました）、期末試験でも全問正解の自信があったので、成績全体で満点に近かったと思います。

期末試験でバグ発見
期末試験は教材持込可で、問題のほとんどは、与えられたソースコードを基に設問に答える形式でした。このコースで学んだ内容を効果的に問う、とてもよく考え込まれた設問ばかりでした。その中で、与えられたコードの問題点を指摘する設問において、出題者の意図と明らかに逸脱したバグを見つけてしまい、試験中に先生に確認したところ、先生は「ボーナスポイントあげる」を苦笑いしていました。

このコースで学んだ内容
冒頭で述べたように、他人が使われることを前提にしたソフトウェアモジュール（メソッド、クラス）を作るのに必要な仕様の定義方法、考え方、同仕様に対する実装方法等を学びました。また、Effective Java第2版の内容を学びました。どれもうなるような奥深さで、毎回クラスや宿題が楽しかったです。特に印象に残っているのは（というか、学んだ内容全て体に染み付けないといけないのですが）、

1. Substitution Principle（継承の原則？）
2. equals()の注意点
3. clone()の注意点
4. Concurrencyの難しさ

1. Substitution Principle
今回のコースを通じて、継承を使うことにはいかに多くの危険性があるかを思い知りました。そして、継承の本質として、「Substitution Principle」の大事さを痛感しました。この本質を分かりやすい例で説明すると、StackクラスはVectorクラスを継承すべきではない、ということです。正直言うと今まで、読みやすい、あるいは重複のない、といったことに注意してコードを書いていましたが、それほど深く考えずに継承を使っていました。特に、他人に使われるであろうクラスを作成するときは、とても気をつける必要があります。

2. equals()の注意点
1.にも関連しますが、インスタンス化可能な親クラスを継承した瞬間、equals()を正しく実装することは不可能だ、という事実を学び、正直驚きました。

3. clone()の注意点
これまた1.にも関連しますが、自分のクラスが他人によって継承可能な場合、コンストラクタを使ってclone()を実装したらアウト、という注意点を学びました。基本的にclone()は使わず、ファクトリメソッドを提供すべきですね。

4. Concurrencyの難しさ
何年経っても、並行プログラミングの難しさには閉口させられます（だじゃれです）。まして、他人が使うことが前提とされているマルチスレッドモジュールを作成する、あるいは他人が複数のスレッドを使ってアクセスするモジュールを作成するとなれば、格段に問題は難しくなります。Effective Javaにおいて何度も参照されている「Java Concurrency in Practice」は、近いうちに読む必要がありそうです。

すでに分かっていることながら、今回改めて痛感したのは、ソフトウェアの品質は開発者の経験および知識によって大きく左右される、ということです。多くの経験と知識を持つ先人がその経験・知識をEffective Javaのような素晴らしい書籍に残してくれるのはとても素晴らしいことだと思います。私達は先人が残してくれた知識を注意深く学ぶべきだと思いました。ただ、どうしても人間は、先輩が注意してくれても自分が痛い目にあわないと十分に理解できないことが多いのではないでしょうか。私も、Javaを学び始めてしばらくしてEffective Javaの第1版を読み、内容を理解したつもりでも「ふーん」ぐらいにしか思えず、その重要さを理解できていませんでした。その後、ある程度実装経験を積んだ段階で、上記のようにそれらを学びなおしてみて「そうそう、これはかなり重要！」と感じ、脳に強く焼き付けることができました。