リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。
⇧ Oh, my gosh...
「リファクタリング」って重要だと思うんですが、曖昧な感じになってしまっているんですね、これはIT業界全体の損失ですね。
でも、安心してください！先人たちが頑張ってくださっていますよ。
で、皆さまご存知、我らが「Martin Fowler」先生です。
⇧ を読んでいて「タイプコード」って言葉が出てくるんだけど、「訳注」によると、
区分コードなどともいう。部分集合のべき型（power type）のインスタンスに応答する。
⇧ っていう説明で、「What's Type Code？」って感じになったんで調べてみました。
レッツトライ～。
Type Code（タイプコード）って？
どうやら、海外でも同じ疑問を抱えている人がおりました。
I'm reading "Refactoring" by Martin Fowler.
There is a term "type code" that I've never seen that before.
What is a type code?
https://stackoverflow.com/questions/10564212/what-is-type-code
⇧ なるほど、原文のほうでもっても説明がないんだと。
プログラミングって、本当に説明をしないで用語を使う風習をいい加減に無くしたほうが良い気がしますけどね...
一見さんお断りで、内輪だけで盛り上がるような、この閉鎖的な雰囲気って、どうにかならんもんかね...
ちなみに、以下が原文っぽいんだけど、
⇧ 「Type Code」で検索したら、「124件」ヒットしたんだけど、「Type Code」が何なのかの説明はないという衝撃...
なるほど、「Type Code」ってのは一般的に存在するものだったか、と思って検索するものの全くヒットせず、つまり「What is Type Code？」に対しては、推測するしかない模様というね...
ちなみに、無茶苦茶に紛らわしいんですが、
⇧「org.omg.CORBA.TypeCode」とは全く関係ありません、たぶん。
What’s type code? Type code occurs when, instead of a separate data type, you have a set of numbers or strings that form a list of allowable values for some entity. Often these specific numbers and strings are given understandable names via constants, which is the reason for why such type code is encountered so much.
⇧ 上記サイト様の説明によりますと、特にプログラミング言語で用意された「データ型」というわけでなく、プログラミング言語を利用する人たちが、利用する人たちの中で独自に定義した定数なんかの実装の集まりを「Type Code」って呼んでるらしい。
なので、Javaの例になるけども、以下のようなクラスがあったとして、その中の「意図した定数の集まり」の部分が「Type Code」ってことらしい。
class Person {
// Type Code
private static final int O = 0;
private static final int A = 1;
private static final int B = 2;
private static final int AB = 3;
private int bloodGroup;
public Person (int bloodGroup) {
this.boolGroup = bloodGroup;
}
public void setBloodGroup (int bloodGroup) {
this.bloodGroup = bloodGroup;
}
public int getBloodGroup () {
return this.bloodGroup;
}
}
とか、
class Employee {
// Type Code
private static final int ENGINEER = 0;
private static final int SALESMAN = 1;
private static final int MANAGER = 2;
private int type;
public Employee (int type) {
this.type = type;
}
public void setType (int type) {
this.type = type;
}
public int getType () {
return this.type;
}
}
ってな具合に、こういう「Type Code」のようなコーディングになってしまっている部分は極力なくしたほうが良いらしいのですが、Martin Fowler 先生によりますと、
- Replace Type Code with Class
クラスによるタイプコードの置き換え - Replace Type Code with SubClass
サブクラスによるタイプコードの置き換え - Replace Type Code with State/Strategy
State/Strategyによるタイプコードの置き換え
の3パターンの方法があるらしい。
■1.Replace Type Code with Class
⇧ クラスを新しく作って、「Type Code」だった部分を解消する方法ですね。
「Type Code」がクラスの振る舞いに関係しない場合に適応する方法だそうな。
■2.Replace Type Code with SubClass
⇧ サブクラスを新しく作って、「Type Code」だった部分を解消する方法ですね。
「Type Code」がクラスの振る舞いに関係してくる場合に適応する方法だそうな。 「Engineer」「Salesman」のように異なるクラス毎に異なる振る舞いが必要になる場合に、ポリモーフィズムを利用する必要があり、サブクラスとするべきなんだそうな。
■3.Replace Type Code with State/Strategy
⇧ 「Gang of Four」ってう「デザインパターン」の中の「Stateパターン」または、「Strategyパターン」を利用して「Type Code」だった部分を解消する方法ですね。
「type code」がクラスの振る舞いに関係してくるんだけど、サブクラス化もできない場合に適応する方法だそうな。
デザインパターンで「Stateパターン」と「Strategyパターン」の違いって？
「Gang of Four」、「デザインパターン」って言葉が出てきたので、そもそも「Gang of Four」や「デザインパターン」って何ぞ？
Wikipediaさんに聞いてみた。
コンピュータ関連におけるGang of Four（ギャング・オブ・フォー、GoF）とは、書籍『オブジェクト指向における再利用のためのデザインパターン』(原題:Design Patterns: Elements of Reusable Object-Oriented Software) の著者である、エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人を指す。
GoFによるデザインパターン（GoFパターン）は、多数のソフトウェアパターンの中で最も広く知られているものである。
⇧ 「Gang of Four」ってのは、『Design Patterns: Elements of Reusable Object-Oriented Software』の著者4人のことを指してますと。
「デザインパターン」はと言うと、
ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。
⇧「設計パターン」のノウハウって感じですかね。
で、「デザインパターン」の中にある、「Stateパターン」と「Strategyパターン」の違いって？
- そのクラス構造やState, Strategyの役割はまったく同一である。
- StateとStrategyの違いは、外出しされるState/Strategyが、オブジェクトのライフサイクルの中で、別のものと入れ替えられうるのかの（設計者による）宣言である。
- 特に、Stateは内部状態が変化しうることをに力点を置いている。
Stateが表すものはベースとなるオブジェクトの「状態」です。
たとえば、TCPセッションというオブジェクトにおいて、その「状態」（未接続、接続中、確立中、切断中etc..）は、ライフサイクル中の外部イベント（相手からの応答があった、切断要求があった、タイムアウトになったetc…）において、別の「状態」に遷移していくものであり、その都度別の「状態」に入れ替わることが前提になります。
一方Strategyが表すものはベースとなるオブジェクトの「種別・タイプ」です。
このタイプはベースのオブジェクトと一体の存在であり、さきほどの例であれば、「三角形」はいつまであっても三角形であって、変わることはありません。（タイプ変換というイベントも考えうることはできますが、これは特別な場合と考えるべきでしょう）
⇧ 違いは「オブジェクト」が変更できるかどうかってことですかね。
UML図を見る感じ、確かに構造はほぼ同じように見えますかね。
■Stateパターン
Define an abstract class that represents the state of an application. Derive a class for each possible state. Each of these classes can now operate independently of each other. State transitions can be handled either in the contextual class or in the states themselves. Information that is persistent across states should be stored in the context. States likely will need to have access to this (through get routines, of course).
■Strategyパターン
Have the class that uses the algorithm contain an abstract class that has an abstract method specifying how to call the algorithm. Each derived class implements the algorithm as needed.
まぁ、脱線しましたが、「Type Code」は極力なくしたコーディングを心掛けていきましょうってことですかね。
「デザインパターン」も勉強せねばですかね。
今回はこのへんで。
