プログラムでも書いてみよう

コピペから始めるTemplateMethod-終

コピペから始めるTemplateMethod-1,コピペから始めるTemplateMethod-2に引き続き今回どのようにして掲題の方法をとるかを記していく。

 

クラスをコピーして新しいクラスを作成したくなった場合の手順である。

 

１．まず元のクラスを2つコピーし、3つのクラスにする。

　　3つのクラスにする理由としては、既存のクラスと新しくコピーされて作成されたクラス、共通部分のクラスとするためである。

　　以降説明では、コピー元のクラスをクラスＡ、新しく作成されたクラスをクラスＢとし共通部分のクラスBaseとする。

↓

 

２．通常コピペで新しく作成したクラスを実装するようにクラスＢを修正して新しく作成されたクラスＢをテストする。

　　このときクラスＡとクラスＢの差分は出来るだけ少なくなるのが望ましい。

例）NewClassBのAddPageメソッドの一部を変更した。

　　 さらにこのメソッドから呼び出す関数としてNewFuncを追加した。

 

そしていよいよ共通化のための作業である。

 

３．クラスＡとクラスＢを比較ソフトなどで比較して差分を見る、差分になっていない部分はそのまま共通化できる部分である。

　　クラスＢａｓｅに対してクラスＡとクラスＢの差分の部分を純粋仮想関数として切り分ける。

 

例）NewClassBのAddPageメソッドのが変更されているのでNewClassBaseにAddPageからコールされるAddPageBと言う純粋仮想関数を追加。

 

４．クラスＡとクラスＢの基底クラスをクラスＢａｓｅにして、クラスＢａｓｅの純粋仮想関数を実装する。

 

５．クラスＡとクラスＢのコードでクラスＢａｓｅの純粋仮想関数を実装した部分以外を全て削除する。

 

上記の手順が「コピペから始めるGOFのTemplate Method」の手順である。

これによるメリットは

１．更なる修正で新たにクラスＡをコピーしてクラスＣを作成したい時、既存のクラスＢａｓｅから派生させクラスＣを実装することが検討でき、次回以降の作業で共通機能をそのまま再利用できるケースが多い。

なぜなら、クラスＡとクラスＢの機能差分は何らかの必然性があって分割されたものである。

であれば同様の要求が出てきた場合、同様の必然性に基づくことが多い。

 

２．パターンは複数クラスによるアルゴリズムのようなものであるためクラス設計に基づき実装していくことが必要であるが、上記の手法を使えばクラス設計が必要ない。

副次的な効果として、パターンの適用は経験に基づくクラス設計が必要であるが、上記を何度か行うことにより経験を養えクラス設計にフィードバックすることが出来る。

 

コピペでコードを増殖させたくなった時、一度この手法をとってみることをお奨めする。

 

自作フリーソフトi-port紹介ページ
http://www.geocities.jp/ys_and_otherjp/index.htm

コピペから始めるTemplateMethod-2

前回の続きですが、コピペしたいコードの共通化について、引き続き記述していきたい。

そこで改めて、Ｔｉｔｌｅの「コピペから始めるTemplate Method」のGOFのTemplateMethodについて説明していきたい。

今回は概念に近い話になるが、私のお奨めするルールを適用する上で必ず必要な概念になるので一読いただきたい。

 

GOFとはGang Of Four（4人のやくざ者？）と呼ばれるオブジェクト指向の識者の書いた、オブジェクト指向のバイブルとなっている「オブジェクト指向における再利用のためのデザインパターン」のことである。

この本には、23種類のデザインパターンが記述されている、デザインパターンとは複数のクラスをルールに従い組み合わせていくことにより目的の処理を行うためのルールである。

オブジェクト指向初心者は「複数クラスを使ったアルゴリズムの雛型」ぐらいで認識しておけばよいであろう。

 

この中のデザインパターンでTemplateMethodと言うのがある。

このパターンは処理の主要部分は既定クラスに機能ごとに処理を変えたい部分を後から実装できるように純粋仮想関数にしておく方法である。

 

たとえば、出席番号・氏名・電話番号を持つデータクラスが有るとする。

このクラスに対して、外部からはRead/Writeを使い保存を行うが保存先がローカルファイルであったりネットワークであったりする仕様の場合、おおよそ以下のクラス図になる。

 

 

StreamAccessクラスは外部からReadがコールされた時、メンバ変数の出席番号・氏名・電話番号をメモリーの配列に変換してSetDataをコールする。

Writeがコールされた時、GetDataをコールしデータをメモリーの配列として取得しそれをメンバ変数に展開する。

 

SetData/GetDataは派生クラスで実装することにより既定クラスのStreamAccessクラスはファイルの保存先がファイルなのかネットワークなのか意識しないですむ。

 

おおよそ、このような感じになるのだが実際にしっかりと設計して実装に入ることはまれであり、担当者が担当部分に対してこのようなパターンを経験に基づき実装していくことになる。

だがしかし、これらは経験に基づきしっかりと自分の知識にした時に利用できるものであり、しっかりと自分のものに出来ていない時そのようにならないことが多い。

 

次回は、実践としてタイトル通り「コピペから始めるGOFのTemplate Method」をこう使いなさいという、私なりのルールを記していこうと思う。

 

 

自作フリーソフトi-port紹介ページ
http://www.geocities.jp/ys_and_otherjp/index.htm

コピペから始めるTemplateMethod-1

掲題の件であるが、いくつかの開発現場に携わってきて私個人でもフリーソフト作成で日々コードを書いている。

その中で、一番嫌いなのがコピペでコードを増殖させる方法である。

コピペは使い捨てプロトでメンテナンスは行わないのでなどの特殊なケースを除いて、デバッグ工数やメンテナンスなどを考えた場合、悪である。

だが開発が差し迫った場合など、コピペをすることで目先の工数を減らしたいと言うジレンマに陥ることは日常茶飯時である。

 

私は、コピペを全面的に否定するわけではないが、ここで改めて考えてほしい。

コピペによる開発をすることはコピペ元とかなり似通ったコードを生成することになる。

逆にいうとコピペ元のソースは、共通化を考えて実装されていないだけで実装方法なりアルゴリズムなり再利用可能な機能を実装していると言うことである。

 

この部分を共通化すること目的とした手順とルールを次回以降に私なりに記したい。

 

自作フリーソフトi-port紹介ページ
http://www.geocities.jp/ys_and_otherjp/index.htm