Mail_Mailer 2.0Mail_Mailer 2.02009/10/272009/10/27

FreeBSE in openpear

アジェンダアジェンダ

Mailer 1.3.0Mailer 1.3.0 から何がかわったかから何がかわったか

設計について設計について

新機能について新機能について

その他の配慮その他の配慮

Mailer 1.3.0Mailer 1.3.0 から何がかわったか？から何がかわったか？

PHP5PHP5 への特化への特化PHP4PHP4 では対応仕切れなかったオブジェクト設計の強化では対応仕切れなかったオブジェクト設計の強化

例えば、オーバーライド禁止、カプセル化やインターフェース等例えば、オーバーライド禁止、カプセル化やインターフェース等

そのため、そのため、 PHP4PHP4 との互換性は完全になくなりとの互換性は完全になくなり

PHP5PHP5 以降専用と化しました以降専用と化しました

PHP4PHP4 のサポートはとっくの昔に、セキュリティフィックス対応も既のサポートはとっくの昔に、セキュリティフィックス対応も既にに

終わっている、且つ終わっている、且つ PHP4PHP4 に拘る必要はないと判断したために拘る必要はないと判断したため

メジャーバージョンをメジャーバージョンを 22 にあげましたにあげました

また、レンタルサーバも順次また、レンタルサーバも順次 PHP5PHP5 へ移行しているようですへ移行しているようです

設計について設計について

内部コードの内部コードの DTODTO 化化メソッドの引数の増減等でバグりやすいのではと考えたメソッドの引数の増減等でバグりやすいのではと考えた

IDEIDE はその点を補えるが、いきなりの更新で引数が変わった際にはその点を補えるが、いきなりの更新で引数が変わった際に

結局は必ず対処しなければならない結局は必ず対処しなければならない (Too few argument etc…)(Too few argument etc…)

引数に該当する変数が同じロジックに使用されているとは限らない引数に該当する変数が同じロジックに使用されているとは限らない

結果↓結果↓

DTODTO 化する事により、決まったキーしか使えなくなるので化する事により、決まったキーしか使えなくなるので

突然キーが使えなくなったり、新しいキーが登場しても突然キーが使えなくなったり、新しいキーが登場しても

中身さえ見れば、使えるキーがわかるし、中身さえ見れば、使えるキーがわかるし、 WarningWarning になってもになっても

わかりやすいエラーメッセージを提供出来るわかりやすいエラーメッセージを提供出来る

同じキー名で違うロジックに使用される事は減る同じキー名で違うロジックに使用される事は減る (( 目的が変わってしまう目的が変わってしまう ))

新機能について新機能について

当然当然 1.3.01.3.0 の機能は踏襲したまま・・の機能は踏襲したまま・・・・

メールの選択削除機能メールの選択削除機能 (addDelete(addDelete メソッドメソッド ))OpenpearOpenpear の利用の利用 (pear(pear コマンドからインストールが可コマンドからインストールが可 ))HTMLHTML メールへの対応メールへの対応

詳細ヘッダーの取得詳細ヘッダーの取得

addCcaddCc メソッドの追加メソッドの追加

addBccaddBcc メソッドの追加メソッドの追加

clearCcclearCc メソッドの追加メソッドの追加

clearBccclearBcc メソッドの追加メソッドの追加

設定の完全設定の完全 DTODTO 化化

getMailgetMail で取得したメールのオブジェクト化で取得したメールのオブジェクト化 (( 例例 $mail->get(‘subject’))$mail->get(‘subject’))メール送信確認機能の追加メール送信確認機能の追加

addAttach(addAttach( 添付ファイル添付ファイル )) メソッドの追加メソッドの追加

clearAttach(clearAttach( 添付ファイル登録消去添付ファイル登録消去 )) メソッドの追加メソッドの追加

使用が可能な機能の一覧表示を行う機能を追加使用が可能な機能の一覧表示を行う機能を追加

その他の配慮その他の配慮

徹底した最適化等徹底した最適化等

正規表現の使用をなるべく控える正規表現の使用をなるべく控える

但し、正規表現を扱って但し、正規表現を扱って 11 回で済ます方法と、正規表現を扱わず回で済ます方法と、正規表現を扱わず 22 回済まさ回済まさないとないと

いけない方法では前者が勝つ、その辺は正規表現関数を使用いけない方法では前者が勝つ、その辺は正規表現関数を使用

PHPPHP の言語構造の使用を多用の言語構造の使用を多用

JITJIT 方式で無駄に方式で無駄に requirerequire しないしない

変数の書き換えを控え、短い変数を新たに追加する事により、速度を向上変数の書き換えを控え、短い変数を新たに追加する事により、速度を向上

また、変数名を短くする事によりメモリ空間の使用量も考慮また、変数名を短くする事によりメモリ空間の使用量も考慮

処理の速い関数を使用処理の速い関数を使用 (( 当然当然 ))

内部ではアクセス不能メソッドや上書き不能メソッドを中心に内部ではアクセス不能メソッドや上書き不能メソッドを中心に

DTODTO によるメソッドへのアクセスを防ぎ、プロパティからそのまま取得によるメソッドへのアクセスを防ぎ、プロパティからそのまま取得

するように処理するように処理

徹底した最適化等 徹底した最適化等 22結果結果 (RC1(RC1 以降以降 ))

ベータベータ 22 以前より以前より (1(1 系統含む系統含む ))

送信送信 (10(10万通仮想送信でテスト万通仮想送信でテスト ))1/31/3 の高速化を達成の高速化を達成

受信受信 (100(100通受信でテスト通受信でテスト ))1/41/4 の高速化を達成の高速化を達成

コードの読みやすさコードの読みやすさ

主要メソッドのコードの前にコメント文をなるべく追加主要メソッドのコードの前にコメント文をなるべく追加

短い変数名でもわかりやすく配慮短い変数名でもわかりやすく配慮

例例 )$mail $eml(OE→)$mail $eml(OE→ の拡張子真似たってのは内緒の拡張子真似たってのは内緒 w)w)

foreachforeach のの $val$val やや $v$v は慣例に従ったは慣例に従った

interface,implementinterface,implement で何が特に重要かを示唆で何が特に重要かを示唆

クラス設計では普通ですが・・・クラス設計では普通ですが・・・

getArraygetArray メソッドを使えば使えるキーがわかるメソッドを使えば使えるキーがわかる

コーディング技法コーディング技法

構造化プログラミング構造化プログラミング

これまた基本中の基本ですが・・・これまた基本中の基本ですが・・・

バリデーション、エラー表示、ファイルチェックバリデーション、エラー表示、ファイルチェック

クラスファクトリー等で使用クラスファクトリー等で使用

エラー発生の時点でエラー発生の時点で returnreturn して処理終了して処理終了

所謂エラーハンドリング所謂エラーハンドリング

エラー処理エラー処理

SymfonySymfony みたくみたく getSubjectgetSubject にしようと思ったが止めにしようと思ったが止め理由としては理由としては

getSubjectgetSubject のところをのところを getTitlegetTitle なんてミスしてなんてミスして

後から確認したら後から確認したら getTitlegetTitle 使用箇所は使用箇所は

全てが全てが Fatal ErrorFatal Error 化する可能性を懸念化する可能性を懸念

また、取得先自体がメソッド名なためまた、取得先自体がメソッド名なため

メソッド名が変わると変更に手間がかかりメソッド名が変わると変更に手間がかかり

開発者側の負担が増大化する可能性を懸念開発者側の負担が増大化する可能性を懸念

ここは柔軟性をここは柔軟性を

EthnaEthna のの appObjectappObject風に風に get(‘title’)get(‘title’) とすれば「キーが違う」と怒られるだけとすれば「キーが違う」と怒られるだけで済むで済む

設定キーを間違えた場合、どのキーを指定しているかをエラーで表示設定キーを間違えた場合、どのキーを指定しているかをエラーで表示

そしたら後は検索すれば、どこに問題のキーがあるか即座にわかる仕組みそしたら後は検索すれば、どこに問題のキーがあるか即座にわかる仕組み

以上！・・・以上！・・・お粗末様でした・・・