MWの、model周りのクラスの継承図なんだけど…なんか色々できたかも。
今までのはそのまま残すんだけど「業務的に楽で便利なプロト」的作り方が一つ増えた感じ?
個人的にはこっちがより主流になると思う。つまり「より楽ができる」w
んと…継承の流れとしては。
今までは
base_model_skeleton
->base_model
-->[業務固有クラス]::function execute()
を基点にして。
認証系は
base_model_skeleton(model 最基底クラス
->base_model(model 基底クラス
-->base_model_rich(認証とかのメソッドがある model拡張クラス
--->base_model_auth_with_mobile
---->[業務固有クラス2]::function execute_auth()
などで対応してたです。
…が、この場合「認証の有無にかかわらず、業務共通の処理」をどこに書くか、ってので悩んでたです。
で、ふと降りてきたお告げ(笑
こんな継承ラインを実装しようと思ってます(多分すぐ)。
base_model_skeleton(model 最基底クラス
->base_model(model 基底クラス
-->base_model_rich(認証とかのメソッドがある model拡張クラス
--->[業務共通基底クラス](全業務共通の処理はこちらに
---->[フロント業務共通基底クラス](同レベルに「管理画面教務共通基底クラス」もいる
----->[個別model]::executeとかexecute_authとか
個別modelで。
executeを実装しちゃえば「非認証」だし。
executeを実装しないでexecute_authだけ実装すれば「認証」でいける。
ambiguous_auth(認証してもしなくても)に関しては、個別modelのinitializeメソッド内で、例えば
$this->ambiguous_on();
とかやればOKなようにしておく。
どんな風に認証をするか(ID/passなのか、契約者固有IDなのかとかその他)については。
フロント業務共通基底クラス/管理画面教務共通基底クラスのinitializeメソッド内で設定。
1メソッドで片付くように、適当に銘々して処理を楽にしておく(って実装は base_model_rich の中に、だねぇ)。
認証のパターンとしては
authentication
・IDでログイン
・契約者IDでログイン
authorization
・Cookieでセッション管理
・契約者IDでセッション管理
のパターンかな。かけ算で、4メソッド用意か…「PCならこうで携帯ならこう」ならもうちょいパターン増やすか。
まぁ「使う時に増やす」でいいよね。
<追記>
そかconfigファイルに持たせてもいいんだな…
そっちのほうがいいのかなぁ?
</追記>
後は。
sampleとかいうディレクトリを作成予定。
ここに、ベースになる「からっぽの業務クラス3種(全体基底、front基底、管理基底)」を作っておくのもよいかも。
さらに追記
実験コード。まぁ予想通りの挙動。
abstract class bms { abstract function exec(); } abstract class bm extends bms { } abstract class bmr extends bm { function exec() { print "bmr exec\n"; $this->exec_auth(); } } //////// abstract class bis_base extends bmr { } abstract class bis_front_base extends bis_base { } class bis_a extends bis_front_base { function exec_auth() { print "bis_a exec_auth\n"; } } class bis_b extends bis_front_base { function exec() { print "bis_b exec\n"; } } // $obj = new bis_a; $obj->exec(); print "-------\n"; // $obj = new bis_b; $obj->exec();
備忘録。っつか健忘録w