┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.55 2004/07/28
■ I N D E X
┃
┣【Topics】新着書籍「リーンソフトウエア開発」リリース！
┣【プログラミング】リファクタリング−プログラミングの体質改善 [9]
┣【キーワード】知ってるようで分からないビジネスキーワード勉強会[11]
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 新着書籍「リーンソフトウエア開発」リリース！
〇 〇━━━━━━━━━━━━━ ━━・
弊社平鍋が翻訳に携わった、メアリー・ポッペンディークの著書「リーンソフ
トウエア開発〜アジャイル開発を実践する22の方法〜」が7月23日、出版され
ました。ご愛読、よろしくお願いいたします。
http://www.objectclub.jp/technicaldoc/bookgide/index_html#lean
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【プログラミング】リファクタリング−プログラミングの体質改善 [9]
近頃ずっと「である調」の文章をしかも長々と書いていたので、自分の文体が
わからなくなったような気がする梅田です。こんにちは。
前回は『属性、操作の横恋慕 - 例外ケース』を紹介しました。今回は『変更
の発散』を紹介しましょう。
[変更の発散で見られる症状]
・様々な要求で、同じクラスが変更される
この症状が見られるということは、ずばりSRPに反しています。SRPとはなにか
というと・・
> 『ソフトウェア原則 [3] SRP(Single Responsibility Principle)』
> SRPでは、「１つのクラスは１つの責務を持つ」を原則とします。複数の責
> 務を１つのクラスに持たせないこと。１つの分かりやすい役割をクラス分割
> の境界とすること。１つのクラス内に入る要素（属性や操作）が、１つの目
> 的に向かって凝集していること。これが原則です。
メルマガ18号から平鍋の記事を引用しましたが、この原則を守っていないと、
色々な責務を抱えた巨大なクラスになってしまうことが多いでしょう。読む気
も起きないクラスには、こういうのが多いですよね。このような場合には、責
務毎に『クラスの抽出』を行うことが大切です。
さて、今回は時計アプリをイメージしてみましょう。時計クラスは、時刻と時
刻表示パネルを持ち、時刻表示を更新する、アラーム時刻を設定する、アラー
ムを鳴らすといった責務を持っています。分析のクラス図を見てみましょう。
--< before >----------------------------------------------------------
┏━━━━━━━━━━━━┓
┃ 時計 ┃
┣━━━━━━━━━━━━┫
┃時刻 ┃
┃時刻表示パネル ┃
┣━━━━━━━━━━━━┫
┃時刻表示を更新する() ┃
┃アラーム時刻を設定する()┃
┃アラームを鳴らす() ┃
┗━━━━━━━━━━━━┛
----------------------------------------------------------------------
例えば、現在の時刻表示がデジタル表示だとしましょう。これをアナログ表示
も可能にするには、この時計クラスに変更が必要ですね。また、アラームの音
色を設定可能にする場合も、この時計クラスに変更が必要になります。このよ
うに、あるクラスが様々な要求で変更されるということは、SRPに反している
と言えます。それでは、見た目に関する部分、アラームに関する部分をクラス
として抽出してみましょう。
--< after >-----------------------------------------------------------
┏━━━━━━━━━━┓ ┏━━━━━┓
┃ 文字盤 ┃ ┃ 時計 ┃
┣━━━━━━━━━━┫ １┣━━━━━┫
┃表示パネル ┃━━━→┃時刻 ┃
┣━━━━━━━━━━┫ ┣━━━━━┫
┃時刻表示を更新する()┃ ┃get時刻() ┃
┗━━━━━━━━━━┛ ┗━━━━━┛
┏━━━━━━━━━━━━┓ １↑
┃ アラーム ┃ ┃
┣━━━━━━━━━━━━┫ ┃
┃アラーム時刻 ┃━━━━━┛
┣━━━━━━━━━━━━┫
┃アラームを時刻設定する()┃
┃アラームを鳴らす() ┃
┗━━━━━━━━━━━━┛
----------------------------------------------------------------------
見た目を変更するときには文字盤クラスを変更し、アラームに関する変更を行
うときにはアラームクラスを変更することで対処できます。世界時計として拡
張されることがあるかもしれませんが、その場合は時計クラスのみの変更でお
終いですよね。このように、責務をうまく分割することで、変更による影響範
囲を狭くすることができますし、変更すべき箇所がより明確にわかるようにな
ります。もちろんソースコードも読みやすくなりますね。
今回は『変更の発散』を紹介しました。わかりにくい点や質問などありました
ら、随時採り上げたいと思いますのでお気軽にご意見をお寄せください。お待
ちしております。（梅田）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+8+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+8+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E002+8+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【キーワード】知ってるようで分からないビジネスキーワード勉強会[11]
「ＴＣＯ」
hiroshiです。最近は猛暑続きで、外を歩くことが多い僕には非常に厳しい時
期がやってきました。皆様、元気にお過ごしでしょうか。7月にあったイベント
も盛況のうちに終了することができ、誠にありがとうございました。懇親会で
は司会を務めさせてもらいましたが、前回以上に盛り上がっていただき、司会
冥利につきました。次回イベントにも是非ご参加ください。よろしくおねがい
します。
さて、今日はTCOについてのご紹介です。TCOとはコンピューター・システムの
総所有コストを意味する「Total Cost of Ownership」の略です。TCOの概念は
1990年ごろに米国で登場しました。
サーバーやパソコンを利用するとなると様々なコストがかかります。主に以下
の5点でコストが発生します。これらのコストの合計がTCOとなります。
(1)ハードの購入やソフトの調達に関わるコスト
(2)操作方法の教育や質問に答えるヘルプデスクのコスト
(3)ソフトのバージョンアップやデータのバックアップに必要なコスト
(4)障害発生時の原因の切り分けや復旧作業のコスト
(5)ハードディスクのデータを完全に消去し、法律に従って廃棄する為のコスト
PCが企業に普及するにつれて、特に(2)〜(4)のコストが増大していきました。
しかし(2)〜(4)の作業は、社内のシステム担当者がこなす仕事の一部となっ
ている為、コストとして目につきにくいものです。TCOはその部分に光を当て
たものです。TCOはコストに焦点を当てているのに対して、以前メルマガで紹
介したROIはシステム化が生み出す利益に対して焦点を当てています。
TCOの削減を軸に登場したのが「シンクライアント(thin client）」です。そ
れは、クライアント側にはブラウザ機能のみを載せるというシステム構築概念
です。これによって、(3)のバージョンアップなどの運用管理コストの削減を
狙っています。
ここでTCOの紹介をしたので、オブジェクト指向や開発プロセスの整備がTCOの
削減にどれだけ効果的なんでしょうか。事例を集めてみたいです。(hiroshi)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+10+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+10+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?D001+10+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「ひと月あたり、何冊の技術書を読んでいますか？」のホントのところ。
次々と新しい動向が見られるこの業界。情報誌、インターネットを走り読みす
る方は多くおられるかと思いますが、技術書の書籍は、月あたり何冊くらい読
まれますか？
平均して10冊以上読みます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+0
平均して7冊〜9冊読みます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+1
平均して3冊〜6冊読みます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+2
平均して1、2冊読みます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+3
平均して本の一部分程度を読みます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+4
技術書は読みません。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+20+6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「一日あたりの最高労働時間は何時間ですか？」の結果は公開中。
是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。今週末は、ひとづてに福井豪雨の話をよく聞きまし
た。「道が川になって流れた」、「上流では家々が壊滅した」、「会社にも出
勤せず、毎日手作業で泥をすくっている」、「漆器の産地がだめになりそうだ」
「学校の校庭や公園は、汚れた家財道具と土砂で埋め尽くされている」等々の
話です。一方、東京のあたりでは信じられない暑さが続いているとかで、次の
夏、その次の夏、その次の次の夏も怖いですよね。ニュースでは、異常気象の
問題を取り上げることが増え、地球温暖化のせいだという話をよく聞きます。
地球環境問題となると、「チームワークが地球人口規模」なので、足並みを揃
えて解決するのは尋常でなく困難だろうな、って思いますよね。また、環境の
問題を目の前の仕事以上に自分にとって緊急だ、と感じる機会もほとんどない
ので、解決性が見えません。ホントは冷える夏なんじゃないでしょうか。ウゥ。
今週の強引な一言
*** 船頭多くして、船、山登る（ことわざ）***
憧れのスーパーチーム。あの人も、この人も実力者。でも、結局は寄せ集めの
チームって事はないですか。実力者同士が足を引っ張りあっても、譲り合いす
ぎてもプロジェクトはうまくいかないものです。役割（責任と権限）をはっき
りして、ベストなポジションで力を出せば、自ずと成功が訪れるでしょう。
（さわ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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.