スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

オブジェクト脳のつくり方

最近、オブジェクト指向についていろいろと思考をめぐらしている。

前回の組合での技術者交流会でも、この1年の成果として、業務アプリケーションとオブジェクト指向、ORマッピングについて発表したのだが、その中で批判的に取り上げたのがこの本。

オブジェクト脳のつくり方

悪い本ではないし、最初読んだときはなかなかいい本だと思った。ただその後いろいろ疑問が出てきた。今日、本屋に立ち寄った際、再度読み返してみた。

どうも著者は構造化分析、構造化プログラミングを知らないように思える。だらだらと長い関数を書くのが構造化プログラミングではない。オブジェクト指向では粒度を細かくしているように書いているが、実際、構造化プログラミングでも同じように粒度を細かくして、モジュール分割して書く。再利用は別にオブジェクト指向が専門というわけではなく、すでにモジュール指向で実現されていた。(おそらくそういう批判を浴びたのかWeb上にあるドキュメントには、「手続き型」とはせず、「よくある設計」としてあったが。)

そして、実際にその本で使用されているサンプルだが、やはりこれもオブジェクト指向とはいえない。デザインパターンを使ったからといって、アーキテクチャーパターン、EJBパターンを使ったからといってオブジェクト指向とはいえない。

データだけでセッターゲッター以外のメソッドを持たないクラス、処理だけでデータがないクラスはオブジェクト指向ではない。DTOを使っている時点でもはや純粋なオブジェクト指向とはいえない。EntityBeanはオブジェクト指向的だが、やはり決まりきったメソッド以外は入れない、込み入った処理は別にするので、データと処理が一体になったオブジェクト指向の本来の目的を果たしているとはいえない。レイヤー分けするのは手続き型言語でもできることである。

デザインパターンを使えばオブジェクト指向になっていると勘違いしている輩も多い。ここでは出てこなかったがSingletonはオブジェクト指向ではない。ステートレスなオブジェクトなので、マルチプルインスタンスであるオブジェクト指向の利点はない。

そもそも業務アプリはオブジェクト指向には向かないというのが私の持論だ。フレームワークの部分と複雑な処理を行っているところは確かにオブジェクト指向が使えるのだが、ロジックの中心となるのはデータベースとSQLなのでオブジェクト指向には不向きである。
オブジェクト指向は、
・シングルユーザ
・処理中心
のどちらかを満たす場合には使える。データ中心でもメーラーのようにシングルユーザならOKだ。しかしマルチユーザの場合、データベースが大きな役割を果たしていると、もはや純粋なオブジェクト指向は難しい。以前、データベースの中身をすべてオブジェクトに展開するプロジェクトを見たことがあるが、結局これは破綻してデータ中心手法で作り直した。大量のメモリ消費、排他制御、検索ロジック等の問題は厄介だ。これらはすべてデータベースに任せておけばいい。
ORマッピングツールも妥協の産物で、個人的にはあまり必要性を感じない。

またポリモーフィズムを使い、インターフェースでプログラミングする、というのがオブジェクト指向であるとの誤解も多い。確かにオブジェクト指向言語によってさらに抽象度は高められた。インターフェースを用いることで、クラスをも抽象化でき、設計と実装とが分離できた。デザインパターンの多くはここに力点が置かれている。とはいえ、これだけではモジュール指向的だ。(プログラミング言語の抽象化の進化については拙HPを読んでいただきたい。)
大切なことは、メンバーが情報隠蔽されていることで、ステートレスなクラスで設計と実装を分離したとしてもオブジェクト指向的ではない。もちろん全体的にオブジェクト指向で組んだ場合でも、その中にステートレスなクラスやstaticなメソッドのみ持つクラスは含まれるが。

オブジェクト指向の本質は、処理をすべてオブジェクト側にさせることにある。それまでのプログラミングでは呼び出し側で使うデータを管理し、適切にモジュールを呼び出して、という形で呼び出し側の管理コストが大きかった。その管理の部分を最小限にし、オブジェクト側にほとんど委任してしまったのがオブジェクト指向だ。それを実現するためにカプセル化とポリモーフィズムがある。
(ただしシングルインスタンスであれば、モジュールでも同じことは可能だ。だからSingletonの使用はオブジェクト指向ではない)

この点一番理解しやすい簡単なサンプルは、ファウラーの
リファクタリング―プログラムの体質改善テクニックの最初に出てくるリファクタリングの例だろう。「餅は餅屋に」で、ことごとく処理をオブジェクトの側にさせるようにリファクタリングは進んでいく。

減ったのはこの管理コストだけで、別にオブジェクトが魔法のように何でもやってくれるようになったわけではない。
ただこうしたことでオブジェクトを自立した存在と見なす、思想も現れた。モジュールよりもずっと柔軟なので、この思想ともマッチする。
ただし、業務アプリにはこの思想は向かない。なぜならデータの中身に意味があるのであって、そのデータ特有の処理はほとんどないから。(続く)

スポンサーサイト

自宅サーバ増設

昨日、新宿に行く用事があって、そのあと目的もなくとソフマップに行った。
中古のパーツを見ながら、そういえば家のサーバ増設する必要があるなと思った。

家にあるのは試験的に入れているジャンク品でVine Linuxを入れている。メモリ128M、HD4Gと今時よく動いているなと思うスペック。作った家計簿アプリを入れるのにちと心配だったので、メモリ、HDともに増設しようと思った。

安いジャンク品に手を出しそうになったが、全く保証なしなのでせめて1ヶ月の保証の利く中古品にした。値段はほとんど変わらなかった。メモリ256Mで1680円、IDEのHD40Gで2980円。店員は最近はこのスペックでこの値段で買えるなんて本当に安くなりましたよと言っていたが、確かに昔を考えるとそのとおりなのだが、今の相場を考えるとこれでも高いのか安いのかよくわからない。

近くの電気屋が閉店のため大売出しをしているのだが、大概10%OFFなので、それでも大して安くない。CD-Rは買って失敗した。ソフマップの方がよほど安かった。Switchを買おうかどうしようか迷っていたが、買わずに正解だった。これもソフマップの方が安かった。他の電気店も安かったので、その電気屋が元が高いだけだった。

さて正しく動作するかとまずメモリからと思ったが、早速ポカを犯した。よく見ずに普通のSDRAMではなくDDRの方を買ってきてしまった。
そしてハードディスク。接続しようと中を開けると、スレーブをつなげるところがない。IDEケーブルが枝分かれせず、1個しかつなげない。近くの電気店をいくつか行ったがいずれも扱っていない。明日、メモリの交換のついでに買ってこようと思う。
ただ、動作チェックをしたかったので、CDにつながっているセカンダリのケーブルを抜いて、それを挿して起動。最初間違えて両方のケーブルを抜いてプライマリとセカンダリを反対につけてしまった。BIOSでブートをセカンダリの方に変えたが、Linuxの起動時にKernel Panicとなって駄目。付け替えて無事起動。

動作チェックをするために、マウントまで実行

#パーティションの作成
fdisk /dev/hdc
n
そしてウィザードに従い、パーティションのサイズを指定し、wで実行。

#ext3でフォーマット
mke2fs -j /dev/hdc1

#マウント
mkdir /hoge
mount -t ext3 /dev/hdc1 /hoge
ls /hoge
でlost+foundが作成されている。ファイルをコピーしてみても問題なし。ということで中古品HDの動作チェック完了。

明日、もう一度、プライマリのスレーブでつなぎ直す。今日のことからすると、もう一度パーティションを切って、フォーマットしなければいけないだろうか。まあ大した時間ではない。

新しいHDへのファイルの移動だが、次の手順でOKか。
1. 適当な名前でディレクトリの作成およびマウント
2. ファイルの移動
3. 1のアンマウント&当該パス名でのマウント

問題は動いているサービスが使用しているディレクトリやファイルだ。移動している最中にも書込みがあったら。特にシスログはどうするか。デーモンを止めるしかないか。

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。