gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

model実装の変更っつか追加予定

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