読書会(Javaの格言)第1回議事録

[ 戻る ]


< 読書会(Javaの格言)第1回議事録 >

                                                          2000/06/18
                                                          文責 高橋智宏

□ 日時 : 2000/06/17 (土) 10:00から16:00まで
  
□ 場所 : 新宿の柏木地区センター
 
□ 参加者 : 遠藤さん、山下さん、石黒さん、橋本さん、鷲崎さん、高橋(徹)さん
            酒井さん、秋池さん、高岡さん、岸田さん、野村さん、前橋さん、
            内山さん、高橋(智)

□ 当日のスケジュール
   1. 自己紹介
   2. 書記の選出
   3. 読書
   4. 昼食
   5. 読書
   6. 宴会



□ はじめに

     今回の課題図書「Javaの格言」は比較的参加し易い本であったためかどうかは
   分かりませんが、参加者数が14人と普段よりも多く非常に楽しい時間を過ごすこ
   とができました。参加者の皆さん、本当にありがとうごさいました。次回の読書
   会にも是非とも参加していただけますようお願い申し上げます。

     「Javaの格言」は、筆者達の経験を「Javaの規則」「設計原則」「ヒント」と
   いう形でまとめたものであり、新たなソフトウェアや解法を生み出すために、コ
   ンポーネント群を「相互配線」する方法に関するヒント集である。
     前半は、「カプセル化」・「継承」・「ポルモルフィズム」について、後半は、
   「イディオム」について書かれている。ただ、読者の素性に応じて、各章の読み
   順が色々と用意されており、中には、章を逆順に読むことを推奨されている場合
   もあった。CLOS経験者がその例だ。



□ 第1章 カプセル化

   ◇  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
     になってしまい困ったという経験。



□ 昼食後の雑談

   ◇  コンピュータ言語の勉強のさせ方に関する話題。

   ◇  近年はプロダクトマネージャという存在があり、コンピュータサイエンスと
     は異質の存在もある。

   ◇  建築業界の作業スタイルと、ソフトウェアの開発スタイルの違いに関する話
     題。



□ 第2章 継承

   ◇  昔(継承を勉強した直後とか)は、やたらと継承を使っていた。
       最近は委譲を使うことが時代の流れになっている。

       矢印BOXの例では、矢印の方向ごとクラスを作っているが、フツーは矢印の方

     向をコンストラクタに渡すのでは? あまり継承は使わないのでは? という意見
     あり。

       汎化は良くありがちなパターンである。繰り返しのコードを見つけて汎化を考
     える。

   ◇  委譲は、共通のコードをくくり出すための別の方法。
       大抵の場合、継承よりも委譲のほうが汎化のための良き形となる。しかし、
     本当に一般的なのかという意見あり。しかも、サンプルのソースはあまり良い
     例ではないかもしれない。

       委譲はパフォーマンス上、継承を利用した汎化よりも有利というが、果たし
     て本当にそうなのかという疑問の声あり。

   ◇  暗黙の継承にいて、昔は必ず "extends Object" と書いていたような気がす
     る。例として、「P.CodeによるJavaオブジェクト設計」のサンプルソースとか。
       C++(MFC)において、CObjectを継承する必要がある場合もあることとは対象的。

       P38. の例では、上のソースと下のソースではどちらも同じコードが生成され

     るのではという意見あり。

   ◇  interfaceについて、interfaceのメソッドの宣言に public が必要なのかど
     うかという話題。パッケージの機能と合わせて考えるとその規準がすこし曖昧
     なのではという意見あり。
       そもそも Java のパッケージスコープに問題があるという意見あり。

   ◇  抽象クラスについては、抽象クラスは本当に必要なのかという意見あり。
     すべてinterfaceで書けるだろうということ。ただ、interfaceは実装するのが
     メンドクサイ。
      
       哺乳類と、哺乳動物の違いは何でしょうか? という話題あり。

   ◇  finalクラスについては、あるクラスをabstractかつfinalと定義すると、コ
     ンパイラはそっけないエラーメッセージを出すそうだ。どんなものでしょうか?




□ 第3章 ポルモルフィズム

   ◇  そもそもポルモルフィズムの機能を説明する必要性があるのか?
     しかしこの本を逆順に読む人もいるので必要なのではないか。また、単に次の
     説明ための土台であり、機械的な説明に過ぎないということか?

   ◇  メソッドの場合と違い、フィールドの場合はオーバーライドされない。コン
     パイル時にどちらを使うか決定されてしまう。親クラスの変数Xと、子クラス
     の変数Xとは別々に存在している。あまりメリットの無い使い方ではある。
     
   ◇  ちなみに、クラスのないオブジェクト指向言語もあるそうです。

   ◇  サンプルのソースにある、FatCatの意味は?

   ◇  複数レベルのポリモルフィズムについて、ダブルディスパッチの定義が分か
     らないという疑問あり。
       ディスパッチの意味は、「切り替え」では?

   ◇  コードの内破(Code Implosion)という言葉は、良い意味である。



□ おわりに

     今回の読書は、案外スムーズに進行し、第3章まで進むことができました。
   本の難易度が低かったからでしょうか。
     読書会の後の宴会も、飛び入りで参加される方もおり、とても賑やかにもの
   でした。みなさん本当にありがとうざいました。


[ 戻る ]