オブジェクト倶楽部クリスマス会「オブジェクト指向実践者の集い」が、予定人員を超えた大人数にて、盛況のうちに実施されました。快くご協力くださった講演者、ワークショップオーガナイザの皆さん。参加者の中にも、著名なオブジェクターが顔を揃え、交流会はかなり「濃い」ものになったようです。了することができました。お忙しい中ご参加くださった皆さん、本当にありがとうございました。ご要望がありました講演資料等は、公開可能なものは近日中に公開いたします。前回は不吉な匂いから『コメント』を紹介しました。今回は予定通り『重複したコード』を紹介します。重複したコードは何が問題なのでしょうか?あなたもこんな経験ありませんか?バグの原因を突き止め、さっと修正し確認。「やった直ったー」と満足なあなた。同じ処理が他にもいるのです。̄*)ちっというわけで、重複したコードはメンテが大変になるという問題を抱えています。他にもコード量が増えることで可読性が下がりやすいでしょう。筆者が良く遭遇するパターンを例に対処法を見ていきましょう。手順1、似た雰囲気のコマンドクラスを丸々コピペ(コピー&ペースト)2、関係ありそうな部分をガリガリ修正(意外と少量)3、完成&コミットってぉぃ。待って!ほとんど重複してるじゃないですか。こいつは対処しないといけませんよね。ここからが対処法の始まりです。『メソッドの引き上げ』まったく同じ(インタフェースも内容も)メソッドがある場合は、それらを親クラスに移動しましょう。言っても、必ず親クラスに移動するわけではありません。メソッドを所有しているクラスの1つを選び、他のクラスはそのクラスに対して処理を委譲するほうが良いケースもありますし、第三者となるクラスを作成して、そこにメソッドを所有するほうが良いケースもあります。Methodの出番です。Methodとは、文字通りテンプレートとなるメソッドです。テンプレートでは、共通のインタフェースを利用することで、子クラス固有の処理と切り離して手順を定義できます。例を見ていただければ、お分かりいただけると思います。}}-----------------------------------------------------------それぞれ線や矩形を作って格納し、さらに描画を行うクラスです。強い構造になりました。親クラスのメソッドを修正するだけで終わりなのです。今回は、不吉な匂いから『重複したコード』を紹介しました。後の拡張が楽になりそうです。次回は、不吉な匂いから『スイッチ文』を紹介する予定です。わかりにくい点や質問などは随時とりあげていきたいと思いますので、気軽にご意見をお寄せください。(梅田)_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。「テスト駆動開発」と「リファクタリング」こんにちは、天野勝です。今回から読まれる方もいらっしゃると思いますので、簡単にこの連載の概要を説明します。Miller(*1)の提案しているXPのプラクティス(*2)を、筆者の解釈にもとづき皆様に紹介していくというものです。今回は開発者のプラクティスである「テスト駆動開発」と「リファクタリング」を説明します。■サンプルコード駆動開発みなさんどうやってプログラミングを覚えましたか。私は、サンプルコードを見て独学しました。このサンプルコードから文法やライブラリの使い方まで覚えました。入門書を選択するときの基準は、ともかくサンプルコードの量です。長い解説を読むよりも、的をついたサンプルコードがあれば、一発で理解できます。この記事を読まれている方の多くも、そんな感じですよね。品コードを書いて、必要に応じてリファクタリングするという作業を繰り返しながら開発を進めていきます。テストコードを書かないことには開発が進められないのです。この「テスト駆動開発」の私にとっての最大のメリットは、サンプルコードがたくさん手に入ることです。テストコードがそのままサンプルコードになるのです。私流に言い換えると別名「サンプルコード駆動開発」です。計書とかを入手しなくても、どうやって使えばいいかがテストコードを見れば分かってしまうなんてうれしいじゃないですか。ちなみに「テスト駆動開発」のメリットとして、製品コードが完成すると同時に、全てのコードのテストが行われている(命令網羅)(*3)というのを第一に挙げる人もいます。プロジェクトマネジメント的にはこのような品質に関わるようなことがメリットなのでしょうが、開発者的にはストレス無く開発が進められるということにメリットを強く感じます。■コードの鮮度を保つ「動いているなら直すな」これは、いにしえより伝わる開発者の鉄則でした。動作しているコードに、わざわざ手を加えて動かなくなってしまうということがよくあります。機能を追加するときは、なるべく既存のコードを変更しないように気をつけます。追加や修正が増えていくと次第に手がつけられなくなります。微妙なバランスで動いている不安定なシステムと化してしまいます。「リファクタリング」では、既存のコードを果敢に修正します。動いているコードでも必要とあらば修正を行い、コードに新しい息吹を吹き込むのです。動いているコードに手を入れるのは確かに不安です。テストコードがあるので、ちょっと直してテストすることが可能です。不安無く機能を追加したり修正したりできるのです。テスト駆動開発とリファクタリングは切っても切れない関係です。2つのプラクティスとせずに、1つのプラクティスとして名前を付けたほうが良いと思っています。テストコードがない場合は、いにしえより伝わる鉄則に従って直さないほうがよいでしょう。リファクタリングについてより詳しく知りたい方は、梅田の記事をご参照下さい。今回は開発者のプラクティスから「テスト駆動開発」と「リファクタリング」を説明しました。次回は、今回と同じく開発者のプラクティスの「ペア・プログラミング」と「集団的な所有権」について説明いたします。この連載に対するご意見お待ちしています。判定条件の全ての組み合わせを実行する条件網羅まで行うのが望ましいです。_______________________________________________________________________この記事への評価にご協力をお願いします。URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用のブラウザに表示されれば投票完了です。┗編集後記こんにちは、編集人です。今週はなんだかリファクタリング特集でしたね(笑)。開発をしている皆さんには、一番身近で実感できるプラクティスではないですか?実際、テストにはいろいろ難しい点もあるとは思いますが。皆さんが一番素敵!と思うプラクティスや原則はなんですか??(いりさ)昨日は、大盛況のうちに、オブジェクト倶楽部クリスマス会を終了しました。講演会、交流会ともに、お忙しい中参加していただき、本当にありがとうございました。皆さん、有意義な時間を過ごすことができましたでしょうか。楽部をよろしくお願いします。