むやみにコアを置き換えるべきでない
Kenji Suzuki
HiroKws さんのブログに興味深い記事がありました。
http://kore1server.com/create-your-site/build-your-own-site/257-fuelphp-browser-validation.html
> FuelPHPマニュアルにはコアを置き換えることも出来るとありますが、だからと
> 言ってむやみに置き換えるのは避けましょう。「コアを置き換える」のは何か
> クールで素晴らしいように感じる気持ちはわかります。たとえば、既に大量の
> コードが存在し、それ全部に修正が必要な場合、コアを置き換えるのも一手で
> しょう。しかし、FulePHPは比較的新しいフレームワークですから、手持ちの
> コードはそんなに多くないはずです。そうであれば、継承して別名の新しいクラス
> を作りそれを利用する、通常の方法で対処しましょう。コードを読む人が理解
> しやすいです。そして、時間が経てば作った本人も忘れてしまうものです。
> プログラム数十年の歴史の中で、数知れず繰り返されてきた悲劇を再び自らの
> 手で起こす必要はないでしょう。
> 更に、コンピューター上の情報を利用する読み手としても、コアを別のものと
> 置き換えていることが、関連する全ページに記述されていないと、無駄に頭を
> 悩ませる事になってしまいます。お願いですから、どうしても拡張したい方は、
> 読者のためその旨を明記し続けてください。読者が、 前の記事を読み、コアを
> 置き換えているのを見つけてくれるだろうとは思わないでください。
どうも CodeIgniter のコーディングスタイルに引っ張られてか、私も Core
を安易に置き換えてしまっていました。
しかし、そもそも Core はできるだけ変更すべきではないものですね。安易に
変更することは避けた方がいいですね。置き換えでなく単純に継承しただけでも、
親クラスが変われば、影響受ける可能性はありますし、fuel はまだ新しいため
Core も変わっていく可能性は高いですし。
また、Core をいじくりすぎると結局オレオレフレームワークになってしまいます。
ということで、Core の置き換えはできるだけしないように改めようと思います。
// Kenji
HiroKws
Kenjiさんが置き換えていたとは、全く知りませんでした。私がこのことを書き加えるきっかけになったのは、最近KenjiさんのFuelPHPに関
するブックマークをチェックしており、その中の記事で、一つはcore下のソースを直接入れ替え、置き換える方法、別の一つはFuelPHPのドキュメ
ント通りの置き換え方の説明がされていました。
その時は、coreのソースの入れ替えはさすがにやり過ぎかなと思いましたが、スルーしていました。その後、自分でValidationクラスを拡張し
ようと思った時、ふと先の２記事を思い出し、そういえば何でコアを置き換える必要があるのかと、後から疑問に思ったわけです。
百害あって一利だけです。理由は記事の中で述べたもの以外にもあります。コアの置き換え記事が増えてしまうと、FuelPHPを知らない方々が読んだ
際、「いちいち置き換えなくてはならない拡張しづらいフレームワーク」であるという印象を与えてしまいます。単に継承し、拡張できるのにです。（継承が
機能拡張のベストな方法かといえば、デザインパターンを学んだ方々に取ってはそうでは無いとは思います。ただ、現状PHPのプログラミングにおいてデザ
インパターンをうまく取り入れ、コアの変更、拡張に柔軟に対応できるフレームワークは存在していませんし、実行効率とのトレードオフにおいて、継承し拡
張するという手法はベターな方法なのだろうと思います。）
私は個人が個人のために利用するなら、どんな改造を行なってもOKだと思っています。オレオレフレームワークも当人にとって最高の道具に育てているので
あれば、賞賛さえします。しかし、その人がFuelPHPに関して情報を書くならば、当然ながら、インストールしたてのバニラFuelPHPを利用する
か、そのオレオレフレームワークについて忘れずに触れてもらうことを期待しています。
もう一つ、こうした記事を書かれている人の中には、現在は学生さんで将来ソフトウェア業界への道を考えている人もいらっしゃるでしょう。そうした記事
を、自分の技術力の証明として、利用する人もいらっしゃるでしょう。そうした場合、コアの書き換えなど、多岐に渡る変更をイメージさせる手法を、簡単か
つドラスティックに紹介していると、「ある程度技術力はあるのだろうが、慎重さに欠ける」と判断されるかも知れません。少なくても、コアの書き換えを紹
介するならば、その影響について言及しておくことをお勧めします。
そしてまだ先ですが、FuelPHP2のリリース時には、多くのことが変化するでしょう。なにせ、開発者はアイデアマンが揃っているらしいですから。何
もかもガラリと変わってしまうでしょう。ですから、継承を利用し拡張せず、どうにか親のコアのまま使って工夫していたとしても、アップグレード時に、新
バージョンに対応させるのなら、既存コードに手を入れることになるでしょうね。どうせ影響受けるわけですし、必要な拡張はバンバンやって構わないと思い
ます。フレームワークのメジャーなアップデートは大抵、真新しいフレームワークに挑戦するようなものですから。
Kenji Suzuki
On Mon, 6 Feb 2012 05:48:53 -0800 (PST)
HiroKws <hir...@gmail.com> wrote:
> おこんばんは、そのHiroKwsです。
>
> Kenjiさんが置き換えていたとは、全く知りませんでした。
公開してる「コンタクトフォーム」のサンプルでやってました。
現在は、置き換えないように修正してあります。
> 私がこのことを書き加えるきっかけになったのは、最近KenjiさんのFuelPHPに関
> するブックマークをチェックしており、その中の記事で、一つはcore下のソースを直接入れ替え、置き換える方法、別の一つはFuelPHPのドキュメ
> ント通りの置き換え方の説明がされていました。
>
> その時は、coreのソースの入れ替えはさすがにやり過ぎかなと思いましたが、スルーしていました。その後、自分でValidationクラスを拡張し
> ようと思った時、ふと先の２記事を思い出し、そういえば何でコアを置き換える必要があるのかと、後から疑問に思ったわけです。
一応、説明しておきますと、CodeIgniter では付属のライブラリを継承して
変更する方法というのがありまして、その場合、通常のライブラリのロード
方法で、変更したライブラリがロードされます。
例えば、Email クラスは
$this->load->library('email');
のようにロードするのですが、元々のクラスが CI_Email で、継承した
クラスが MY_Email だとすると、MY_Email クラスが所定の場所に
ある場合はロードされインスタンス化されます。
そういう流儀になっています。
私の場合は、よく考えずに、これに合わせてしまったということです。
しかし、確かに FuelPHP でそのようにする必要はほとんどありません。
> 百害あって一利だけです。理由は記事の中で述べたもの以外にもあります。コアの置き換え記事が増えてしまうと、FuelPHPを知らない方々が読んだ
> 際、「いちいち置き換えなくてはならない拡張しづらいフレームワーク」であるという印象を与えてしまいます。単に継承し、拡張できるのにです。（継承が
> 機能拡張のベストな方法かといえば、デザインパターンを学んだ方々に取ってはそうでは無いとは思います。ただ、現状PHPのプログラミングにおいてデザ
> インパターンをうまく取り入れ、コアの変更、拡張に柔軟に対応できるフレームワークは存在していませんし、実行効率とのトレードオフにおいて、継承し拡
> 張するという手法はベターな方法なのだろうと思います。）
> 私は個人が個人のために利用するなら、どんな改造を行なってもOKだと思っています。オレオレフレームワークも当人にとって最高の道具に育てているので
> あれば、賞賛さえします。しかし、その人がFuelPHPに関して情報を書くならば、当然ながら、インストールしたてのバニラFuelPHPを利用する
> か、そのオレオレフレームワークについて忘れずに触れてもらうことを期待しています。
> もう一つ、こうした記事を書かれている人の中には、現在は学生さんで将来ソフトウェア業界への道を考えている人もいらっしゃるでしょう。そうした記事
> を、自分の技術力の証明として、利用する人もいらっしゃるでしょう。そうした場合、コアの書き換えなど、多岐に渡る変更をイメージさせる手法を、簡単か
> つドラスティックに紹介していると、「ある程度技術力はあるのだろうが、慎重さに欠ける」と判断されるかも知れません。少なくても、コアの書き換えを紹
> 介するならば、その影響について言及しておくことをお勧めします。
> そしてまだ先ですが、FuelPHP2のリリース時には、多くのことが変化するでしょう。なにせ、開発者はアイデアマンが揃っているらしいですから。何
> もかもガラリと変わってしまうでしょう。ですから、継承を利用し拡張せず、どうにか親のコアのまま使って工夫していたとしても、アップグレード時に、新
> バージョンに対応させるのなら、既存コードに手を入れることになるでしょうね。どうせ影響受けるわけですし、必要な拡張はバンバンやって構わないと思い
> ます。フレームワークのメジャーなアップデートは大抵、真新しいフレームワークに挑戦するようなものですから。
今でも、Core は少しずつ変化してますので、1.2 でも思いがけず影響を被る可能性も
あります。
クラスの分割が行われ、実際のメソッドが別のクラスに移動したというのがありました。
結局、Core を置き換えても、害が多いだけでほとんどいいことはないということですね。
// Kenji