読書会(Javaの格言)第1回議事録
[ 戻る ]
＜ 読書会(Javaの格言)第1回議事録 ＞
2000/06/18
文責 高橋智宏
□ 日時 : 2000/06/17 (土) 10:00から16:00まで
□ 場所 : 新宿の柏木地区センター
□ 参加者 : 遠藤さん、山下さん、石黒さん、橋本さん、鷲崎さん、高橋(徹)さん
酒井さん、秋池さん、高岡さん、岸田さん、野村さん、前橋さん、
内山さん、高橋(智)
□ 当日のスケジュール
１. 自己紹介
２. 書記の選出
３. 読書
４. 昼食
５. 読書
６. 宴会
□ はじめに
今回の課題図書「Javaの格言」は比較的参加し易い本であったためかどうかは
分かりませんが、参加者数が14人と普段よりも多く非常に楽しい時間を過ごすこ
とができました。参加者の皆さん、本当にありがとうごさいました。次回の読書
会にも是非とも参加していただけますようお願い申し上げます。
「Javaの格言」は、筆者達の経験を「Javaの規則」「設計原則」「ヒント」と
いう形でまとめたものであり、新たなソフトウェアや解法を生み出すために、コ
ンポーネント群を「相互配線」する方法に関するヒント集である。
前半は、「カプセル化」・「継承」・「ポルモルフィズム」について、後半は、
「イディオム」について書かれている。ただ、読者の素性に応じて、各章の読み
順が色々と用意されており、中には、章を逆順に読むことを推奨されている場合
もあった。CLOS経験者がその例だ。
□ 第１章 カプセル化
◇ privateというキーワードが、「ボックスを封印」し、クラス間の依存度を下
げる。
Javaは本質的にマルチスレッドであり、コードをカプセル化する必要がある。
（ちなみに、筆者はマルチスレッドの専門家であるようだ。）
このルールが守られていない例として、java.awt.Pointがある。パフォーマン
スを考慮した結果かも知れないが、クラスのカプセル化とパフォーマンスを維持
する方法がある。final修飾子である。
また、すべてのprivateメソッドはfinalとして扱われる。
◇ インスタンス変数には最後尾に "_" を付けるというコーディング規則の紹介
◇ 筆者はデフォルトの「パッケージスコープ」の利用を避けるように言ってい
る。
protectedの修飾子は、デフォルトのパッケージ内のアクセスを許すが、何故
protectedはこのように弱い立場なのか(笑)という意見があった。
ちなみにpythonにはpublicしかないそうです。
そもそもデフォルトのパッケージアクセスの存在意味がないように思われると
いう意見もあり。
◇ P12. の getReferenceNumberメソッドは、上位を"0"で埋めていない。バグで
はないかという意見あり。
◇ NumberFormatExceptionはランタイムの例外である。これはアプリケーション
側に柔軟に対応してもらうようにすめためではないか?
しかし、そもそも NumberFormatException を catchしない開発者はいないの
ではないか? だが現実は違うようだ。
◇ インナークラスについて、staticなインナークラスは実際使われているのか?
一部ではあるが使われている製品があるようだ。
インナークラスの主たる用途は、JDK1.1以降のイベントモデルにしかない。
◇ JDKのListクラスは、パッケージに関してメンドクサイことを強いられる。
typedefするとか。
◇ import文に関して、
・.*を使うか、フルで記述するかというコーディングへの姿勢。
・ソース中の不要なimport文を発見したい。
・JBuilderは勝手に必要なimport文を追加してくれる。
ということが話題に上った。
◇ インナークラスをシリアライズすると親クラスも暗黙のうちにSeriarizable
になってしまい困ったという経験。
□ 昼食後の雑談
◇ コンピュータ言語の勉強のさせ方に関する話題。
◇ 近年はプロダクトマネージャという存在があり、コンピュータサイエンスと
は異質の存在もある。
◇ 建築業界の作業スタイルと、ソフトウェアの開発スタイルの違いに関する話
題。
□ 第２章 継承
◇ 昔（継承を勉強した直後とか）は、やたらと継承を使っていた。
最近は委譲を使うことが時代の流れになっている。
矢印BOXの例では、矢印の方向ごとクラスを作っているが、フツーは矢印の方
向をコンストラクタに渡すのでは? あまり継承は使わないのでは? という意見
あり。
汎化は良くありがちなパターンである。繰り返しのコードを見つけて汎化を考
える。
◇ 委譲は、共通のコードをくくり出すための別の方法。
大抵の場合、継承よりも委譲のほうが汎化のための良き形となる。しかし、
本当に一般的なのかという意見あり。しかも、サンプルのソースはあまり良い
例ではないかもしれない。
委譲はパフォーマンス上、継承を利用した汎化よりも有利というが、果たし
て本当にそうなのかという疑問の声あり。
◇ 暗黙の継承にいて、昔は必ず "extends Object" と書いていたような気がす
る。例として、「P.CodeによるJavaオブジェクト設計」のサンプルソースとか。
C++(MFC)において、CObjectを継承する必要がある場合もあることとは対象的。
P38. の例では、上のソースと下のソースではどちらも同じコードが生成され
るのではという意見あり。
◇ interfaceについて、interfaceのメソッドの宣言に public が必要なのかど
うかという話題。パッケージの機能と合わせて考えるとその規準がすこし曖昧
なのではという意見あり。
そもそも Java のパッケージスコープに問題があるという意見あり。
◇ 抽象クラスについては、抽象クラスは本当に必要なのかという意見あり。
すべてinterfaceで書けるだろうということ。ただ、interfaceは実装するのが
メンドクサイ。
哺乳類と、哺乳動物の違いは何でしょうか? という話題あり。
◇ finalクラスについては、あるクラスをabstractかつfinalと定義すると、コ
ンパイラはそっけないエラーメッセージを出すそうだ。どんなものでしょうか?
□ 第３章 ポルモルフィズム
◇ そもそもポルモルフィズムの機能を説明する必要性があるのか?
しかしこの本を逆順に読む人もいるので必要なのではないか。また、単に次の
説明ための土台であり、機械的な説明に過ぎないということか?
◇ メソッドの場合と違い、フィールドの場合はオーバーライドされない。コン
パイル時にどちらを使うか決定されてしまう。親クラスの変数Ｘと、子クラス
の変数Ｘとは別々に存在している。あまりメリットの無い使い方ではある。
◇ ちなみに、クラスのないオブジェクト指向言語もあるそうです。
◇ サンプルのソースにある、FatCatの意味は?
◇ 複数レベルのポリモルフィズムについて、ダブルディスパッチの定義が分か
らないという疑問あり。
ディスパッチの意味は、「切り替え」では?
◇ コードの内破(Code Implosion)という言葉は、良い意味である。
□ おわりに
今回の読書は、案外スムーズに進行し、第３章まで進むことができました。
本の難易度が低かったからでしょうか。
読書会の後の宴会も、飛び入りで参加される方もおり、とても賑やかにもの
でした。みなさん本当にありがとうざいました。
[ 戻る ]