これはよいことだと思う。前提条件として、職員がFacebook上でプライベートな書き込みをしていて、それを市民からどうのこうの言われたとしても、市が職員を守ること。そういう雰囲気が一般化していくと、同じ人物にもプライベートと仕事があるんだなあという、当たり前のことがWWWでも広く認識されるのではないか。
武雄市長物語 : 武雄市職員は全てFacebookアカウントを取得。
オブジェクト指向より手続き型の設計がいいのかねえ
・前処理をするクラス
・本処理をするクラス
・後処理をするクラス
・エラー処理をするクラス
という風にクラスが分かれているとしたら(この表現でニュアンスが伝わるかな？)、それはオブジェクト指向言語を使っていたとしても、手続き型の設計だよね。
でも手続き型も長い歴史をもった流儀なのだし、オブジェクト指向言語でオブジェクト指向設計をしていないから悪だというわけでもなく、むしろ積極的に手続き型の流儀を使っていくべきなんですかねえ。少なくともそういう書き方を好むプログラマーが複数いるのは知ってる。
迷ったらラップしとけ的な
実装とか、実装に近い設計部分なのだけど、かっちりと作るべきところと、遊びを持たせて作るべきところがあって、逆になりがちなところでもあるし、気をつけていきたい。(べき、は言いすぎだが)
かっちりと作るべきなのは個々の機能で、これらは1関数1機能の原則を守るべきだし(どっちもfunctionだ)、引数の型も厳密にしておくべき。PHPだとDBをselectした結果だの、XMLやJSONをパーズした結果だのが配列(連想配列)で扱うことができるので、つい引数も連想配列にしてしまうが、型だけみてると、なんというテーブルを、どんな風にselectした結果なのか見えてこない。面倒なように見えるがオブジェクトでラップすべき。
一方、遊びを持たせるのはどこかというと、個々の機能を連結するところ。ここをついかっちりと作ってしまうことが多い気がする。目の前の問題を解決するためのフレームワークを作るのだ、という発想になったら危険信号。目の前の問題は常に変化するはずだし、フレームワークはそう簡単には変化させられない(と思うんだけどねえ。設計うまい人はまた違うのかな)。なんかのインタフェースを実装したオブジェクトがこんな値を返すんだ、と思ってたら、メタ情報を持たせられないとかね。XMLをパーズした結果の連想配列を返すようにしてたけど、やっぱりXMLファイルのタイムスタンプも欲しいとかなったらどうするのか、とかとか。こういうのもやっぱりオブジェクトでラップしておくと便利だったりする。
テンプレの変数のスコープが微妙
Smartyとかのテンプレの変数って、アサインされてる前提で使うし、まあアサインされてなくてnullのときにも動くようなプログラミングもするけど、どうにも気になる。
doSomething(Hoge $hoge) とかの関数だとしたら、Hoge型の$hogeが使えるのは一応保証されてるけど、テンプレだとそうでもないんだよね。foo.php から hoge.tpl を呼ぶときは動くとして、 bar.php から hoge.tpl を呼ぶと何かの変数が入ってなくて動かないとか。
例えば hoge.tpl は hoge.php からしか呼ばないというようなコーディング規約で縛るという手もあるにはあって、なんでそういう規約があるのかと思ったけど、やっぱり意味はあるんだなあ、とか。あるいは displayHoge() を経由して hoge.tpl を表示する、みたいな規約にすると、もうちょっと柔軟になる。
とはいっても規約で縛ったりラップしたりするのも気持ち悪いには違いないんだよな。
医学の分野では科学的根拠が必要で、自分の経験ではこの薬で治るとかいうのだとどうも駄目っぽくて、二重盲検法とかで検証した大量のデータが必要になるっぽい。
いっぽうプロジェクトマネジメントだとか開発手法とかの話だと、自分の経験ではこうやったらうまくいった、という程度で本が出てたりするよね。
この差ってなんなんだろ。
Atom Feed