┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.37 2004/03/10
■ I N D E X
┃
┣【オブジェクト入門】暴いておやりよＯＯバッキー[2]
┣【プログラミング】リファクタリング−プログラミングの体質改善 [5]
┗【アンケート】気になるシステム業界 ホントのところ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【オブジェクト入門】暴いておやりよＯＯバッキー[2]
筆者が非オブジェクトな時代から今まで経験した、オブジェクト指向での自ら
の失敗を取り上げてＯＯバッキ−に断罪させるコーナーです。
登場人物
ＯＯバッキー：性格が悪い子猫。
オブジェクト指向の勘違いを指摘していじめるのが何より好き。
Ｕ君 ：ＯＯバッキーの飼い主。いつもＯＯバッキーにいじめられている。
気が弱い。オブジェクト指向の初心者。
ＯＯバッキー：ニャー！俺ＯＯバッキー。
オブジェクト指向の勘違いを探しにやってきた子猫なんだ。
勘違い野郎はどこにいるのかニャー。
ＯＯバッキー：ニャー。なんじゃこりゃ。
これを書いたのはご主人様なのかニャー？
Ｕ君 ：え、なんなの？僕のソースなんかおかしかったかなぁ。
--------------------------------------
public class JuchuMeisai {
private String strProductCode; // 商品コード
private String strProductName; // 商品名
private int iTanka; // 単価
private int iSuryou; // 数量
private int iKakaku; // 価格
:
/**
* 価格取得の関数
**/
public int getKakaku(int tanka, int suryou) {
iKakaku = tanka * suryou;
return iKakaku;
}
:
--------------------------------------
ＯＯバッキー：ニャー。やっぱりご主人様だったのかニャー。
芸術的な非オブジェクトだニャー！
Ｕ君 ：えぇ〜。がんばって作ったのに。何がいけないのさ。
ＯＯバッキー：人間、結果が全てだニャー。
突込みどころ満載だから整理するニャー。
１．属性とローカル変数の違い
２．カプセル化
３．接頭句
まず、１．だニャー。getKakaku()の中で価格は数量と単価で求
められているから、private int iKakakuはまったく不要だニャー。
たまにクラスの属性を変数の定義みたいにして使っている人が
いるけど、まさにご主人様だニャー！
Ｕ君 ：え〜。クラスの最初の変数って、Cをやってるときは最初に定義
したよ？
ＯＯバッキー：ダサダサだニャー。オブジェクトはデータとロジックをもって
いるが、クラスが持っているデータを属性というのだニャー。
それを表しているのが、メソッドの外に書いている定義
（private String ...など）なんだニャー。メソッドの中で使
用する変数だからじゃないんだニャー。
次に２．だニャー。価格を取得するメソッドgetKakaku()だニャー。
Ｕ君 ：えへん。たとえば受注明細に関するロジックは受注明細クラス
に書くんだろ。だからこう書いたんだ。文句あるの？
ＯＯバッキー：だから素人は困るんだニャー。ママに電話でもしたほうがいい
んじゃないかニャー。
Ｕ君 ：…。（涙）僕は猫以下なんかなぁ。
ＯＯバッキー：そのとおりだニャー。これだと、たとえば引数の数が変わった
ら、このメソッドを使っているクラスは全て変更だニャー。
変化ヲ抱擁セズで、変化ニ法要サルという感じだニャー。
南無阿弥陀仏。
Ｕ君 ：じゃどうするんだよ。
ＯＯバッキー：こうだニャー！
------------------------------------------
public int getKakaku() {
return getTanka() * getSuryou();
}
------------------------------------------
受注明細のクラスはすでに単価と数量を持っているんだから、
それで計算すればいいので、引数なんていらないニャ。ご主人
様のコードだと引数で、単価と数量を渡しているので、逆に属
性がなんの意味もないんだニャ。これだと、内部の計算ロジッ
クが変わっても、getKakaku()を使っているクラスでは変更がな
いんだニャ。こんなのカプセル化の基礎だニャ。
Ｕ君 ：なるほど。確かに便利そうだね。
ＯＯバッキー：最後に３．だニャー。
属性とかにいちいちintのiだとかStringのstrとかつけるのは
Javaとかじゃやらないニャー。接頭句をつけるのは、たとえば
だらだらとした長いコードを書くときに、変数の型がわからな
くなるからで、Javaでまともにコーディングすると、そんな長
いメソッドができることはないから、そんなのつけるだけ、重
複なんじゃないかニャー。意味のある名前を付けるほうがよっ
ぽど重要だニャー。
Ｕ君 ：でもJavaでも長くなることもあるよ。
ＯＯバッキー：それはクラスがちゃんと設計されていないんだニャー。逆に長
くなったら、怪しい設計だと思うほうが健康なんだニャー。最
後に俺様だったらこう書くってコードを見せてやるニャー。ロー
マ字を英語に変えているけど、そこはあまり重要じゃないニャ。
俺様の趣味だニャ。コメントを取っているのも俺様のスタイル
だニャ。コメントを書かないといけないようなところは、名前
の付け方や複雑なロジックがあるようなケースが多いから、
Javadocで必要なところと、どうしても説明できない部分にぐら
いしか書かないニャ。
--------------------------------------
public class OrderLine {
private String productCode;
private String productName;
private int unitPrice;
private int quantity;
:
/**
* 価格を取得する
* @return 価格
**/
public int getPrice() {
return getUnitPrice() * getQuantity();
}
:
--------------------------------------
こうしてＵ君が一生懸命作ったコードが今日もバッキーによって葬り去られた
のでした。
暴いておやり、ねぇ子猫。僕の育てたＯＯバッキー。
おなかつつけば語りだす真実を・・・。
ＯＯバッキーに断罪してほしい、失敗ネタをお持ちのかたは
ぜひネタをご提供ください。（OO槻ケンジ）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?I001+1+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?I001+1+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?I001+1+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】リファクタリング−プログラミングの体質改善 [5]
さて、前回は不吉な匂いから『長すぎるメソッド』を紹介しました。今回は予
定通り『多すぎる引数』を紹介します。引数が多すぎるとこんなことが起きま
すよね。
[引数が多いときに見られる症状]
・メソッドが読みにくい
・メソッドが再利用しにくい
読みにくいことは、保守にも拡張にも悪影響を及ぼします。これって多分、毎
回言ってますね。けれど、リファクタリングの目的が『ソースコードを読みや
すくシンプルに保つこと』にある以上しかたないので、「あ〜またか〜」と軽
く流しておいてください。
引数が多くて読みにくい・再利用しにくいときには、単純にメソッドの扱う範
囲が広すぎて、たくさんの情報を必要としていることも多いように感じます。
そういうときはまず、前回紹介した『長すぎるメソッド』の対処法を適用する
ところから始めると良いでしょう。それでは、今回は３つのリファクタリング
を紹介しましょう。
『メソッドによる引数の置き換え』
呼び出し側がある値を取得（算出する場合も含みます）し、その値をメソッド
の引数として渡しています。このとき、受信側でもその値を取得可能なら、引
数から削除し、メソッド内で取得するようにしましょう。
『オブジェクトそのものの受け渡し』
あるオブジェクトから複数の値を取得し、それらの値を引数として渡している
ときは、元のオブジェクトを引数にして、メソッド内で値を取得しましょう。
ただし、引数となるオブジェクトに対して依存関係を持ちたくない場合もある
ので、状況に応じて適用しましょう。
『引数オブジェクトの導入』
まとめて扱うべき一連の引数がある場合に適用できます。ある引数のグループ
が色々なメソッドで現れる場合には、一度考えてみる価値があるでしょう。こ
のリファクタリングを実行すると、当然引数が短くなるわけですが、それ以上
の効果を期待することもできます。具体的に述べると、このような引数を集め
たクラスを作成した場合、このクラスに含まれるべき共通の操作が見つかるこ
とがよくあります。見つかった共通の操作を新しいクラスの振る舞いとして定
義することで、抽出元のメソッドやクラスがシンプルなものになり、さらに、
重複したコードの削減にもつながります。
それでは、今回は『引数オブジェクトの導入』のサンプルを紹介します。サン
プルを元に色々なシチュエーションを想像して、効果を感じてみてください。
--< before >--------------------------------------------------
public class Product {
public int getPrice(Date start, Date end, Date current) {
if (start.after(current) && end.before(current))
return DISCOUNT_PRICE;
else
return NORMAL_PRICE;
}
}
--< after >---------------------------------------------------
public class ServiceTimeRange {
private Date start;
private Date end;
pubilc boolean includes(Date current) {…}
}
public class Product {
public int getPrice(ServiceTimeRange range, Date current) {
if (range.includes(current)) return DISCOUNT_PRICE;
else return NORMAL_PRICE;
}
}
--------------------------------------------------------------
※あれっ...あんまりシンプルになったように見えない...(^-^;
今回は、不吉な匂いから『多すぎる引数』を紹介しました。今回の内容は、わ
かりやすいだけでなく、適用したいケースを見かけることも多いと思います。
身近なコードで是非お試しください。
次回は、不吉な匂いから『巨大なクラス』を紹介する予定です。わかりにくい
点や質問などは随時とりあげていきたいと思いますので、気軽にご意見をお寄
せください。お待ちしております。（梅田）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+4+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+4+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+4+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗気になるシステム業界 ホントのところ
今週は「システム業界に多い血液」のホントのところ。今週のテーマは噂では
なく、単純に編集室の疑問であります。さて、どんな結果が出るでしょうか。
A型です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+0
B型です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+1
O型です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+2
AB型です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+3
実はわかりません。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+4
それは秘密です。
http://objectclub.esm.co.jp/cgi-bin/question.cgi?Z001+3+5
ちょっと語らせて！
editors@ObjectClub.esm.co.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部HP上にて公開します。お楽しみに。
なお、前号「プログラマ35歳定年説」の結果は公開中。是非ご覧下さい。
⇒http://www.objectclub.jp/ml-arch/magazine/question/index.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
お待たせいたしました、前回大好評でした、牛尾さんの記事、第2作目の登場で
す！記事への評価へのご協力、感想メール等、お待ちしています。
今週の強引な一言
*** 薬も過ぎれば毒となる（ことわざ）***
デザインパターンを取り入れることで再利用性のよいソフトウェアに仕立て上
げることができますが、使いすぎるとパフォーマンスが悪い、開発に時間がか
かるなどの弊害も出てきます。XPにおけるプラクティスもこれまた然り。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.