せっけいほうほうとかそういうの

オブジェクト指向とか構造化分析設計とかを全然違うように語る人もよくいると思うんですけど、オブジェクト指向が世の中に出始めてしばらくは今みたいに全然違うものに見えることはなくむしろ単なる拡張に見えた時期もあったんですよね〜そんなわけで今度出る記事でもごちゃ混ぜで書けるんですけど(笑)で、いろんな言語がオブジェクト指向を目指し始めてからは逆にプログラムを構造化設計していては言語とあんまっちするのでプログラムはオブジェクト指向で設計するのが良いね。でも、それ以前の部分はやっぱ構造化分析でしょうと・・・理由は割と簡単なんですけど、利用者に見せて判ってもらえる図が多いんですよ(笑)構造化なドキュメントって圧倒的に丸と四角が多いじゃないですか、何のひねりもない図がわかりやすいと・・・で、それで全体像を書ききればあとはオブジェクト指向でプログラムを如何に楽に簡単に仕上げるかで脳に汗をかかせるって作業じゃないですか。今のところこれが最高のやり方だと思いますよ。詳細は今月発売の雑誌に全部書いてるのでそれ見てください(笑)
両方共通で作るのが面倒な事もよくあるんでそこの解消のためには色々なテクニック等を駆使するか新しいやり方を見つけ出さなきゃなぁ〜って感じですね。
チャーハン修行中・・・おいしいチャーハンを作れるようになるまで何度でも・・・フッ素樹脂加工のフライパンだったら絶対楽なんだろうなぁと思いつつあれには頼らず作りたい！そんなわけで時々チャーハン作りを楽しんでいますとさ。
上のところで両方共通で作るのが面倒云々って書いてたら、ほその日記にありました、「ワークフロー」こいつはホントに作るのが面倒、何度作ってもifの嵐になりかねない。大体そんな条件減らした方が仕事上良いんじゃないの？って思うくらいの条件がずらずらとあるんですけどね(笑)
ワークフローの設計方法は作りたてほやほやでStar内部のMLに流したのでとりあえず実装について・・・
ワークフローは大体、データの現在の条件＋ログインしているユーザの条件＋データの過去の状態の条件でアクションが決まると思うんですよ。（これまで何となくこういうのが多かった気がする）んなわけで肝は、「なるべくわかりやすく書く」（それだけかい！）下手にコードを最適化せずにずらずらと条件を並べ上げるのも一つの手だと思う、あとは、「条件式を一カ所にまとめる」この２点である程度軽減できるんだけど、次なる問題は一覧の時！条件に応じて表示が色々変わる！とっても困ったやつ。「なるべくSQL一発で表現できる方法を見つけ出す」それができないときは力業で書かずに一覧のループのなかで「条件を先に表示を後に」ってやると比較的きれいなコードが書きやすくなる。（その分変数が増えるんだけどね）あと、先にでてるまとめられた条件式を上手につかっていけば比較的楽かなぁ〜
ちなみになんでワークフローって作りにくいかのちょっとした説明
ふつうのプログラムは条件でデータを見つけ出すっていうのが基本としてあるんですね。プログラムっていつも条件を作るじゃないですか、でもワークフローはデータから条件を見つけ出すんです。そのワークフローを従来のプログラム言語で作ろうとするからとっても作りにくいんですよ。まぁそんなこんなで楽しみなプロダクトが一つあるんですけどね（笑）
そんなわけで、簡単にワークフローが作れるものを探すのはちょっと無茶かも（笑）