ナビゲータのEVEです。
12月も半ばになり、クラス製造も佳境に入ってきました。スケジュール的にかなりやばいって感じです。
開発するにあたり、今までの開発方針と考えが変わったので、その点についてご報告します。
[機能によりクラスを分ける]
エラーメッセージクラスを製造し、そのエラーメッセージクラスを各クラスでextendsするにあたり、すべてのクラスを基本機能と複雑な機能といった分類で、親と子に分けて、管理しようと考えてきましたが、やめることにしました。理由は、エラーメッセージクラスでログを出力するように仕様を変更することを検討を始めてからでした。
[ログへ出力する]
PSR-3では、ログに関する規約が用意されているのですが、今現時点は、対応していません。理由は、ログの出力は、業務に関連することに限定しようと考えているからです。
現在製造しているのは、クラス、メソッドでそこで発生したエラーをいちいちログに出力するのは、エラーを残す目的とはなりえないと考えたからです。
そのため、現在各クラスでインポートしているエラーメッセージクラスでは、ログを出力していません。しかも、エラーメッセージだしね・・・。名前からもログを出力するというイメージないしね・・・。
ただ、そろそろ、画面設計をして、どの国からアクセスしてくるのかとか、ユーザーのことを考え始めてから、ログのことを考え始めました。
[ログへ出力するタイミング]
そんなログの出力するタイミングですが、やはり、エラーメッセージクラスあたりで出力したいですよね？ただ、現在のクラスの仕様を変更しようとすると、いろいろなクラスへ影響がでてきます。そこで、考えられるのが、エラーメッセージクラスの継承です。そうなんですよね？？？こういう時に、クラスを継承すべきなんじゃないかなって思ったわけです。その考えを思いついたとき、今まで文字クラスを基本的な文字操作のものとその基本的な操作を利用する複雑な文字列操作に分けて親と子にしようとか考えましたが、ちょっと違うかなって思うようになりました。意外と親の機能を子が使うケースってないしね・・・。PHP組込関数豊富だしね・・・。ただ、もし文字列クラスを親と子で分離しないと、文字列クラスの場合、5,000ステップ近くあるので、システムパフォーマンスへの影響を心配しています。
っという心配は現時点もあるのですが、PHPもJITが機能として追加され、ハードもここ数年かなり良くなっているので、忘れることにしました。
[あとがき]
文字列クラスは基本機能と複雑な文字列操作のものとに既に分けたのですが、近日中に統合します。そして、これからは、文字列、数値、ファイルとか言った単位で何も考えずに作っていきます。迷っちゃうと手が止まってしまうんですよね？しばらくは悩まず製造できそうです。そして、子クラスを作るタイミングは、エラーメッセージクラスへログの機能を追加しなければならないといったタイミングで、作らなければならない時に作ることにしました。
PSR-3の規約の取り込みというかログの出力の部分については、1月から始めることにしました。PSR-3を読んでみると分かるのですが、統一的にログとして出力することができそうです。ただ、ファイルに出力するのか、データベースに出力するのかといった問題をまだ考えていません。PSR-3自体にはどこに出力するのか定義はなく、自由度が高いのはいいのですが、その辺をきちんと考えてから製造しないと運用してから困ったことになりそうです。また、その辺の考えをまとめ、ブログという形で残すことがありましたら、御意見等いただければうれしいです。
では、また！
【このカテゴリーの最新記事】
