わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
私は、 プログラムを理解するのに必要なことはソース中に書け(コンパイラのチェックも通るし)。中でも重要なことはできるだけ一箇所に集中して書け。 よって、コメントは最後の武器だ。 ましてプログラムをドキュメントで説明するのは敗北宣言だ。 よって、データ型やテーブル定義を見れば、プログラム全体が理解できるようにすべきだ。 型なし言語逝ってよし。 ぐらいに思っている人間なので、これには賛成しかねます。 http://d.hatena.ne.jp/kmaebashi/20090430/p1 正しく伝わっていないので補足します。上記の5点は激しく同意です。オブジェクト指向分析の一歩がインスタンスの抽出であるように、ソースコードの解析もデータ構造の把握から始めるのが一番だと思っています。 RDBの一番の問題は、アプリケーションとDBの両者でデータ構造を定義していて変更コストが高いところじゃないかなぁ。
「業務アプリの業務部分で、オブジェクト指向なんか使わないよね」（Re)という話が出てますのでちょっと思うところを書いてみます。 オブジェクト指向の究極は、オブジェクト指向であることがみえなくなるのだと思う。 フレームワークって言うのがまさにそうで、フレームワーク自身が設計の多くをまかなう故に、オブジェクト指向設計をさせない作りになる。テンプレートメソッドのメソッドを埋めればアプリとして動作する。例えばGrailsを使う場合、アプリをくむ立場からはオブジェクト指向の要素はほとんどありません。でも使ってない訳じゃなくて、間接的に使っていて、使っていることが見えないほど巧妙になっているだけ*1。 クラスライブラリというのもそういうものです。継承を多用させるなど、オブジェクト指向を熟知することを利用者に強要するようなクラスライブラリは、API設計としてはよろしくない。 しかし、それは、オブジェクト
久々の更新なのでちょっとは刺激的なことを書いてみる。 今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。 しかし、煽りでもなんでもなく、実のところ現場ではあまり使わない、というのも事実だったりします。 そりゃ、ライブラリやフレームワークでは使いますよ。しかし、多くのプロのプログラマが会社で作るような「業務アプリ」の世界において、プログラム全体の中でライブラリやフレームワークの占める割合は大きくはない。10万行のシステムを書いて、5万行が(自社開発の)共通ライブラリやフレームワークだというのなら、それはおそらく設計が間違っています。まず8割以上は「業務ロジック」のプログラムになるんじゃなかろうか。 そして、たいがいの「業務アプリ」は、フロントエンドがWebであろうがクライアントアプリであろうが、データの本体はRDBMSにあり、それを操作するのはSQLです。よって、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
