機能を増やそうとすると、どうしてもフラグを立ててif文やswitch文の連打になってしまいます。
No.5
200
2
50pt
WebプログラマはRailsに乗るべきか？
http://www.atmarkit.co.jp/fjava/column/andoh/andoh29.html
どの言語で開発するかに関わらず、規約を決めて自動的にハンドリングできるように設計することです。
URLを http://host/app/command と決めてcommand 名でファンクションを呼び出すようにすれば機能を増やす時も分岐命令を増やす必要はなくなります。
No.1
81394
50pt
PHPに限ったことではないのですが、function() を使ってサブルーチンを沢山作り、if や switch からはサブルーチンを呼び出すだけにするという方法が一般的かと思います。
http://www.shigeweb.jp/php/project_p/?section=first&page=fun...
if や switch を沢山使うのは仕方ないと思います。次期の拡張に備え、常にソースを見やすくすることが得策なのではないかと思います。
ありがとうございました。
ソースのメンテナンス性の重視にも気をつけたいと思います。
No.3
50834
50pt
http://www.thinkit.co.jp/free/marugoto/1/5/1/
URLはPHP5のXML関係の記事です。
今日の自分のコードは明日の他人のコードという言葉があるように、
コードを美しく設計するのはもちろんのことですが、
ログを出力する関数を作成しておき、
すべてのファイルにincludeしておけばよいのではないでしょうか。
また、これは私の趣味の範囲なのですが、インタフェースと、DBアクセスのファイルは分けておき、一発でDBアクセスに関するディレクトリはここ！と分かりやすくしておくことです。
ちなみに私はPHP５でもあまりオブジェクト設計していません。
PHP4の時にデストラクタがない等えらい苦労をさせられたので。
なんというか、もう一息頑張って欲しいのですよ。
ありがとうございます。
ログ出力は参考になりました。
設計も重要ですが、原因究明を楽にする方法も合わせて用意しておくのは安心で良いですね。
No.4
1593
50pt
オブジェクト指向でやるか、サブルーチンでやるかは
個人の好みの問題だと私は思います。
どちらでやるにしろ、小さい処理や機能ごとに分割しておく事で
コードの使いまわしも出来るようになります。
あと、ifやswitchが多くなるの必然です。
それなりに大きい物を作ろうと思うとそうなってしまいます。
上の人も書いてある通り、ソースを見やすく書くのもいいと思います。
例えば、インデントをきちんとするとか
適切にコメントを付けるとか
変数名を自分なりの規則で統一するとか。
ダミーURL
ありがとうございます。
if文の多さは必然なのですか。よく世にあるオブジェクト指向の本ではif文とかを蛇蝎の如く嫌っているんじゃないかと思えるような場面に出くわすことが多いので、新鮮でした。
読みやすいソースのルールを整備するのも、結果として拡張しやすいように造る道の一つではありそうなので、コーディング規約を考えてみます。
No.5
2002
ここでベストアンサー
50pt
WebプログラマはRailsに乗るべきか？
http://www.atmarkit.co.jp/fjava/column/andoh/andoh29.html
どの言語で開発するかに関わらず、規約を決めて自動的にハンドリングできるように設計することです。
URLを http://host/app/command と決めてcommand 名でファンクションを呼び出すようにすれば機能を増やす時も分岐命令を増やす必要はなくなります。
ありがとうございます。
ruby on rails、DBの関連づけがすごいですね。
自分には出来そうもないと考えていたんですが、本当に拡張性をどうにかしたいと考えるなら避けて通れないような気がしました。
少し気になったのは、command名でファンクションを呼び出すというところです。
確かにそれだけに絞れば分岐はなくなりますが、本当に単機能に絞らないと実現できなさそうで、どのようにしてcommand名を特定するのかが気になります。
例．
1のとき /app/command1
2のとき /app/command2
（区別するために分岐が必要？）
結局、command名を呼び出す部分には分岐が入ってしまいそうですが……。
No.6
2002
50pt
call_user_funcのような名前で関数を呼び出す仕組みを利用します。
コマンド名と関数名の変換規約が一つなら、関数を呼び出す部分は一度作るだけで済みます。
なるほど。
関数を呼び出す部分を統一することで、分岐を意識することなく、command名を開くだけで実行できますね。
呼び出し部分の統一によって変数のエスケープや妥当性検証のフィルタとしても応用がききそうで、面白そうです。
さすがにこの関数を使ったサンプルソースは見つからないですね…。
ありがとうございました。いろいろ試して体得していきたいと思います。
No.7
110
50pt
ネスト（ソースコード内で字下げする深さ）が５～７レベルより深くなっているようであれば、「何かおかしいのではないか？」と思ったほうが良いと思います。
ソースを書いていて、コードをコピ－＆ペーストするときには注意しましょう。「本当にこのコードはコピーすべきなのか？」「関数にしたほうが良いのではないか？」
ごく一般的な原則としてこのようなものがあります。
・同じコードを複数回書かない（DRY (Don't Repeat Yourself) 原則といいます）
・コードをできるだけシンプルに保つ
・マジックナンバー（数値定数をそのままコードで使用すること）を使わない
・変数、関数に一貫性のある、良い名前をつける
ある機能について、関数とフラグの組がある程度揃ってきたらクラス化する、というのも手です。（あまり周囲との依存性が高いと使いづらいクラスになるので注意）
その他、プログラムをシンプルに保つ方法については「リファクタリング」で検索するといろいろ出てくるものと思います。（PHPに関するものは少ないかと思いますが、プログラミング全般に適用できる考え方です）
リファクタリング―プログラムの体質改善テクニック
http://www.amazon.co.jp/exec/obidos/ASIN/4894712288
以下も一読の価値ありです。
Ｃプログラミング診断室（こちらのURLで本の内容がすべて読めます）
リファクタリング、早速買って読んでいます。
ソースの修正を定常的に行うという発想に感心しました。
しかし、会社がクラス禁止の関数のみでコーディングしなければならないことが判明し、当分使う機会はなさそうです。
PHP5なのにC言語を書いている気分です。はふー。
137
137
1
4
2
ありがとうございます。
ruby on rails、DBの関連づけがすごいですね。
自分には出来そうもないと考えていたんですが、本当に拡張性をどうにかしたいと考えるなら避けて通れないような気がしました。
少し気になったのは、command名でファンクションを呼び出すというところです。
確かにそれだけに絞れば分岐はなくなりますが、本当に単機能に絞らないと実現できなさそうで、どのようにしてcommand名を特定するのかが気になります。
例．
1のとき /app/command1
2のとき /app/command2
（区別するために分岐が必要？）
結局、command名を呼び出す部分には分岐が入ってしまいそうですが……。