Date:  Wed, 18 Aug 2004 12:31:09 +0900
Subject:  【オブジェクト倶楽部: 2004-30号】

       ┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
       ┃                         ■┃
      ●┃● ● オ ブ ジ ェ ク ト 倶 楽 部   ■ ┃
       ┃                       ■  ┃
       ┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
                          No.58 2004/08/18

■ I N D E X
┃
┣【Topics】モデリング道場HP開設!!
┣【プログラミング】リファクタリング−プログラミングの体質改善 [10]
┣【キーワード】知ってるようで分からないビジネスキーワード勉強会[12]
┗【アンケート】気になるシステム業界 ホントのところ

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
 〇  モデリング道場HP開設!!
  〇 〇━━━━━━━━━━━━━ ━━・ 
先週ご案内しました、モデリング道場。今週よりHPも公開です。
http://www.objectclub.jp/community/modeling
モデリング道場のMLに参加したい!!という方、まずは
modeling-dojo-ctl@objectclub.jp宛に、subscribe ≪名前≫という本文一
行のメールを送ってみてください。

例:(平鍋 健児さんの例)
subscribe Kenji Hiranabe

たくさんのみなさんの参加、お待ちしております。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】リファクタリング−プログラミングの体質改善 [10]

こんにちは。梅田です。前回は『変更の発散』を紹介しました。今回は『変更
の分散』を紹介しましょう。キーワードだけ見ると、とても似てますよね。い
つまで経っても間違えてしまいます・・。

[変更の分散で見られる症状]
・1つの変更を行うときに、色々なクラスが変更される

1つの変更を行うために複数のクラスを変更しなければならないことは、何が
問題なのでしょう。第一に、変更箇所が散らばっているため理解するのが難し
くなること、第二に、変更すべき箇所を見落とす危険が生じることです。
対して、前回紹介した『変更の発散』は、1つのクラスが複数の変更要求の影
響を受けることでした。こちらの問題は、1つのクラスが必要以上の責務を抱
え込むために、巨大なクラスになりやすいことでしたね。
これら2つの不吉な匂いをまとめると、「1つの変更要求があった場合に、変
更が必要となるクラスが1つであるのが良い設計」ということになります。

『変更の分散』を解決するには、「メソッドの移動」や「フィールドの移動」
を行って、変更部分を1つのクラスにまとめあげます。既存のクラスから良い
移動先が見つからない場合は、新規にクラスを作成しましょう。
とはいっても、これだけでは実感が伴わないと思いますので、『変更の分散』
の特殊ケースである不吉な匂い『パラレル継承』を簡単なサンプルとともに紹
介しましょう。『パラレル継承』とは、新たなサブクラスを定義するたびに、
別の継承ツリーでもサブクラスを定義しなくてはならない状況を指します。今
回は少々抽象的な例になります。

--< before >----------------------------------------------------------
       ┏━━━━━┓
       ┃ 機能1 ┃
       ┗━━━━━┛
          △
     ┏━━━━┻━━━━┓
     ┃         ┃
┏━━━━━━━━━┓┏━━━━━━━┓
┃コンソール版機能1┃┃GUI版機能1┃
┗━━━━━━━━━┛┗━━━━━━━┛

       ┏━━━━━┓
       ┃ 機能2 ┃
       ┗━━━━━┛
          △
     ┏━━━━┻━━━━┓
     ┃         ┃
┏━━━━━━━━━┓┏━━━━━━━┓
┃コンソール版機能2┃┃GUI版機能2┃
┗━━━━━━━━━┛┗━━━━━━━┛
----------------------------------------------------------------------
この例では、機能に対するユーザインターフェース(以下UI)の違いを継承で実
現しています。このとき、コンソールに対する修正が必要になると、コンソー
ル版機能1とコンソール版機能2の2つのクラスを修正しなくてはなりません。
また、コンソール版とGUI版に加えて、新たなUIを持たせる場合には、機能毎
に新しいサブクラスを作成する必要がありますし、新しい機能を作成する場合
には、全てのUI分のクラスを作成しなくてはなりません。これは大変ですね。

それではまず、コンソールなどのUIに修正が必要な場合に、修正クラスが1つ
になるように変更しましょう。コンソールクラスとGUIクラスを新規に作成
して、各機能のサブクラスにあるUI固有のフィールド・メソッドを移動しまし
ょう。そして、各機能のサブクラスからは、それぞれのクラスへUI固有の処理
を委譲するように変更します。
----------------------------------------------------------------------
       ┏━━━━━┓
       ┃ 機能1 ┃
       ┗━━━━━┛
          △
     ┏━━━━┻━━━━┓
     ┃         ┃
┏━━━━━━━━━┓┏━━━━━━━┓
┃コンソール版機能1┃┃GUI版機能1┃
┗━━━━━━━━━┛┗━━━━━━━┛
     ↓         ↓
  ┏━━━━━┓    ┏━━━┓
  ┃コンソール┃    ┃GUI┃
  ┗━━━━━┛    ┗━━━┛
     ↑         ↑
┏━━━━━━━━━┓┏━━━━━━━┓
┃コンソール版機能2┃┃GUI版機能2┃
┗━━━━━━━━━┛┗━━━━━━━┛
     ┃         ┃
     ┗━━━━┳━━━━┛
          ▽
       ┏━━━━━┓
       ┃ 機能2 ┃
       ┗━━━━━┛
----------------------------------------------------------------------
これで、UIに修正が必要になっても、修正するクラスは1つになりました。し
かし、UIや機能が増えた場合に大変なのは相変わらずです。次に、それぞれの
UIに共通のインターフェースを与えることで、各機能毎にそれぞれのサブクラ
スの処理を共通化しましょう。そうすることで、サブクラスの処理をスーパー
クラスに引き上げ、各機能毎の継承構造をなくすことができます。

--< after >-----------------------------------------------------------
   ┏━━━┓   ┏━━━┓   ┏━━━┓
   ┃機能1┃━━→┃U I┃←━━┃機能2┃
   ┗━━━┛   ┗━━━┛   ┗━━━┛
             △
          ┏━━┻━━┓
          ┃     ┃
       ┏━━━━━┓┏━━━┓
       ┃コンソール┃┃GUI┃
       ┗━━━━━┛┗━━━┛
----------------------------------------------------------------------
これで、UIや機能が増えても、作成するクラスは1つだけになりました。最初
の構造と比べると、格段に良くなっていますよね。

今回をもちまして、梅田が日頃気になった不吉な匂いを中心にとりあげてきた
この連載を終了いたします。長らくお付き合いくださいましてありがとうござ
いました。さらにリファクタリングを知りたい方は、書籍『リファクタリング
プログラミングの体質改善テクニック』をご覧になってください。お勧めです。
それでは、また何らかの記事でお会いしましょう!(梅田)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+9+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+9+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+9+2

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【キーワード】知ってるようで分からないビジネスキーワード勉強会[12]
              「バイオメトリクス認証」

hiroshiです。今回はバイオメトリクス認証について、紹介していきます。

バイオメトリクス認証(Biometrics Identification)とは、指紋、虹彩、声な
ど、個人ごとにユニークな生体情報を用いて本人認証を行う仕組みで、近年注
目を集めている技術です。なぜ生体情報がこのように注目を集めるようになっ
たのでしょうか。パソコンのログインなどで、IDやパスワードを利用する場
面を思い浮かべてください。パスワードが平易、あるいは管理がずさんな場合
は「なりすまし」が容易です。そのためセキュリティーの脆弱さが大きな問題
となります。とはいっても、複雑な記号のようなパスワードを暗記するのも難
しいですね。こうしたセキュリティを取り巻く状況の中で、暗記する必要も、
特殊な認証器具(ICカードなど)も必要ない、人が生まれつき持っている生体情
報での認証が求められてきているのです。さらに最近では、個人情報の漏洩事
件が相次ぎ、より強固なセキュリティが求められている中で、バイオメトリク
ス認証があらためて注目を集めているのです。

バイオメトリクス認証は、その精度や固有性など、他の認証ツールと比べると
多くの優れた点があります。しかし、その認証方式にも課題が無いわけではあ
りません。とりわけ大きな課題は「すべての人が利用できるわけではない」と
いうことです。生体情報が時間とともに変化してしまい、保管されている情報
と食い違ってしまったり、そもそも生体情報を採取できない人がいたりなど、
誰にでも利用できるものではないからです。その場合、その人はシステムその
ものを利用できないことになってしまうため、認証ツールベンダーは必ずバッ
クアップの仕組みを持っていて、IDやパスワードで別途認証できるようにする
ことが一般的です。しかし、バイオメトリクス認証においては、これが完全な
るセキュリティホールとなってしまいます。

以下に生体情報の種類を挙げます。ざまざまなものから情報を取得し、認証に
役立てていることが分かります。

指紋    :指先の指紋を利用した認証方法
虹彩    :瞳孔の薄膜組織模様を利用した認証方法
サイン  :筆跡、筆圧を利用した認証方法
声紋    :発音時の声紋を利用した認証方法
顔      :顔形状を利用した認証方法
静脈    :静脈パターンを利用した認証方法
網膜    :網膜の表面血管パターンを利用した認証方法
掌型    :掌の幅、長さ、厚さなどの形状を利用した認証方法

最近のバイオメトリクス認証の動向を探ってみたいと思います。
国際的な標準化の動きが2002年より継続されていて、現在ではISO(国際標準化
機構:International Organization for Standardization)の下部組織で、国
際標準のための規格案を策定している状況です。時期については未定ですが、
2004年10月よりアメリカで導入が進められているパスポートへの生体情報導入
に関する動きが活発になることで、標準化が急がれるだろうという予想です。
さらに、国内ではスルガ銀行で静脈認証を導入しました。2004年7月にスルガ
銀行が「バイオセキュリティ預金」という金融商品を発表しました。これは手
のひらの静脈パターンを事前に登録し、預金を引き出す際の本人確認の手段と
して利用することで、高い安全性を確保するという仕組みです。また、東京三
菱銀行では、キャッシュカード利用の安全性を高めるため、同様の手のひら静
脈を読み取る現金自動預け払い機(ATM)の導入を決定しています。

最近の情報漏えい問題や、テロの問題によって、個人認証は今回紹介したバイ
オメトリクス認証のようによりユニークな方向に進んでいます。僕が小さいこ
ろには映画の中のことだったことが、最近は携帯電話に指紋認証や、金融機関
を中心に静脈認証などが導入され、徐々に身近になってきています。口座のカ
ードや会員証など持ち歩くのが面倒くさい僕はもっと進んでくれたら、楽なの
になと感じています。以上です。(hiroshi) 
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった:
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+11+0
普通:
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+11+1
イマイチ:
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+11+2
 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ

今週は「この夏、泳ぎに行きましたか?」のホントのところ。

お盆になって、そろそろ海のシーズンも終わりですね。屋外プールだと9月の
半ばくらいまで泳げるところもあるようなのでまだまだシーズン真っ盛りなの
かもしれませんが、夏=海!!!と思ってしまう私は田舎者なのでしょうか。
いつも室内でパソコンとにらめっこで、色白の人が多いイメージがあるシステ
ム業界ですが、この夏泳ぎに行った人はどのくらいいらっしゃるのでしょうか。
みなさんの投票、お待ちしてます。

  行きました。日焼けに苦しみました。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+0
  今後行く予定です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+1
  時間ができたら行きたいなぁ。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+2
  行く暇なんてないです。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+3
  それより他にやりたいことがあります。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+4
  泳ぐの嫌いです。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+5
  それは秘密です。
     http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+23+6
  ちょっと語らせて!
     editors@ObjectClub.jp まで詳細を!!

アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「生まれ変わっても今と同じ仕事をしたいですか?」の結果は公開
中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人です。長く続いた「リファクタリング−プログラミングの
質改善」もついに今回をもって、連載終了を迎えてしまいました。(T_T)。
(「リファクタ〜」のライターの梅田さんは、締め切りを守ってくれるありが
たいライターだったので編集人としても名残惜しくて仕方がありません)。
しかし、このカスカスな編集後記を書くのにすら苦しんでいるような私として
は、締め切り後でもとにかく原稿をいただければ、ありがたいので困ります。
たまには、木刀持ってライターを追いかける気概を持ちたいものです…。オブ
ジェクト倶楽部も世間サマの波に乗って忙しくなってきているため、なかなか
新しくライターをしようという人が現れません。私はライター探しの旅に出る
ので…今日はこの辺でさようなら。

今週の強引な一言
*** 子曰、學而不思則罔、思而不學則殆
(論語 巻 第一 爲政第二 :原文)***
「子曰わく、学んで思わざれば則ち罔(くら)し。思うて学ばざれば則ち殆
(あや)うし。 (書き下し文)」
学んでも考えなければものごとははっきりしません。考えても学ばなければ独
断に陥って危険です。(さわ)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行:オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表:平鍋  健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.