開発言語によりますが、変数（とくに状態管理）やメソッドを束ねることがオブジェクト指向のメリットで、それ意外のことは「考えない」ほうが、一人で何かを高速で作る場合は「速い」と思っているところです。
簡単なアプリならば、Railsなどのフレームワークでちょちょいのちょいで作るという選択肢なんかもありなのですが、結局のところリリースして改善し続ける場合は、初期のスピードよりも継続的に改良していく時間的コストを下げるべき。
ブラックボックスなところが多くて、外面的にどう考えても簡単な修正だけど、工数が出せません！なんてことは避けたい。
…そうなると、変化に柔軟に対応するプログラムコードとは、シンプルで簡潔にリファクタリングし続けたコードってことになり、OOPがどうたらとかいう話はわりとどうでもいい。
ほどよい関数抽象や名前空間/スコープを用いた局所化をこまめに行うことが大切。
無理に共通化や再利用性に頭もたげるくらいならばさっさと作れ！…ありきたりな抽象関数ならば共通関数化でことたりるし、そうでないばあいは特定処理の親クラスに定義しておけばOK。
これはOOPではありません。
疎結合性も意識していない。
デザインパターン？そんなの知りません。
手続き型的な構造プログラミングの延長に関数をグループ化したスコープすなわちモジュール化のみを考慮してプログラムを書き、フレームワークの知識しかない方には、セキュリティ面で注意する点だけ伝えれば開発できるはずです。
例えば、ORMのトランザクション制御とか、SQLが難しいと言うような人は、どうしてよいかわからないです。それくらい慣れてほしいというのは、無理強いでしょうか？WEBアプリ開発の専門家になるならば、必須知識ですと言い切ります。
OOPしているのがコーディングだと思っているなら、別に止めませんけど、そういうものが至上だと思っているグループに所属して、少なくとも１０年くらい揉まれていればいい気がします。私が尊敬するプログラマのラリー・ウォールが言うように「there’s more than one way to do it (物事のやり方は一つだけではない)」なのですから。
※ラリー・ウォールの名言は「プログラマの美徳」が取り上げられることが多いけど、there’s more than one way to do it.のほうが名言だよなー。（ぼやき
コメント