買い物ログ別館

『オブジェクト指向入門』の読書記録です。

まずはP.35の練習問題2.1をやってみます。

問題

2.1 プログラミング言語のモジュール性

よく知っていてその機能を評価できるプログラミング言語のモジュール構造を調べてみよ。この章で説明した基準と原則を満たしているだろうか。

わたしにとってはいきなりハードな問題です。

モジュール性の基準と原則

この章での基準と原則とは次のとおり。

5つの基準

• モジュールの分解しやすさ
• モジュールの組み合わせやすさ
• モジュールのわかりやすさ
• モジュールの連続性
• モジュールの保護性

5つの原則

• 言語としてのモジュール単位
• 少ないインターフェイス
• 小さいインターフェイス
• 明示的なインターフェイス
• 情報隠蔽

C++でまずは漠然と考えてみる

わたしが最も理解している言語であるC++について、「モジュール構造」といえるものが何かを考えてみましょう。

素朴に考えると、C++におけるモジュール構造の代表的なものはクラスでしょうか。C++におけるクラスは上記基準を満たしているか? ってのはどう考えたらいいか見当もつかないので、原則について考えてみましょう。

言語としてのモジュール単位

モジュールは使用する言語の構文単位に対応していなければならない。

クラスがモジュールである、って考えているのだから、当然この原則には合致しますね。

しかし複数のクラスが集まったモジュールというものを考えたときには、C++は言語的にサポートできていません。言語レベルではなく処理系と環境のレベルでは、たとえば動的ライブラリにするとかいった手段がありますが。

少ないインターフェイス

モジュールはできるだけ少ないモジュールと対話すべきである。

C++のクラスでもとくに問題なく実現できます。でもこの原則には合致しないように書くことも容易です。

小さいインターフェイス

2つの対話するモジュールがある場合、それらが交換する情報の量は出来る限り少なくなければならない。

C++のクラスでも問題なく実現できますが、すべてをglobalにおいてべたべたに依存したりすることもできます。あるいはすべてを公開メンバにしてお互いべったりのクラスを書くことだってできます。

明示的なインターフェイス

モジュールAとBが対話する場合、その対話は必ずAあるいはB、もしくはその両方のテキストから明らかにならなければならない。

この原則は正確な意味がつかめません。暗黙のうちに対話に影響をあたえるなにかがあってはならない、ということなのでしょうが、具体例が思い浮かびません。

情報隠蔽

とくに公にすると宣言されていない限り、モジュールに関する情報はすべてそのモジュールのみに属する非公開の情報である

クラスのレベルではこの原則に合致しています。しかし複数のクラスによるモジュールでは実現が困難です。

以下次号

難しいなあ。

このへんでペンをおいて頭をひやします。つづきは明日(の予定)。

投稿者: こじま 日時: 23:18 | パーマリンク | コメント (0) | トラックバック (0)

学生時代は経験がないうえにバカだったので、いろんな本を読んだけど投げ出したり理解していなかったりしました。

『オブジェクト指向入門』(Bertrand Meyer, 酒匂寛・酒匂順子訳)もそんな本のひとつです。

当時の私は、オブジェクト指向ってのはちょっと便利な構造化プログラミングくらいにしか思ってませんでした。意味よりもメカニズムに興味がいってたし。

オブジェクト指向がちょっとわかったかも、とおもったのはずっと後になって『Refactoring』(Martin Fowler)を読んだときでした。

でもその後、設計・実装経験をそれなりに積んできても、未だにオブジェクト指向を「完全に」理解できている気がしません。いろいろ本を読んでみたけどおお理解できた！ という境地に達しません。もやもや。

最近誰かの日記でメイヤー先生のこの本への言及をみつけました。「こういう古典に戻ればよかったんだ！」といまさら気づき、読み始めました。前置き長いな俺。

わたしはいまだにバカですが、経験を積んだ分学生時代よりは理解できるんじゃないかなと希望的観測。いまさら読むのかよ、おせーよ俺、と思いますが、でも読まないよりはましですよね。

というわけでこの記事は個人的事情をだらだらと書いた前置きだけで終わります。まて次号。

投稿者: こじま 日時: 22:43 | パーマリンク | コメント (3) | トラックバック (0)

だいぶ前に興味をもったけどずーーっと放置状態だったRailsをやっといじりはじめ。作業メモ。

Ruby環境修正

tigerのrubyは環境にいろいろと問題があるそうで、何か作業をしたはずなんだけど一年近く前なのでおぼえてないです。この件についてはこのあたりが最新情報かな?

ruby gemsのインストール

これも一年近く前で具体的作業を憶えてないです。

XAMPPのインストール

XAMPP for MacOS Xを入れます。

railsのインストール

 % sudo gem install rails

MySQL/Rubyのインストール

Ruby/MySQLでMySQL 4.1相手にすると、Bad handshakeになってしまいますのでMySQL/Rubyをインストールしようとしたらなんかうまくいかんでした。わかってしまったらこの程度ですが

 % sudo gcc_select 3.3
 % sudo gem install mysql  -- --with-mysql-config=/Applications/xampp/xamppfiles/bin/mysql_config

gcc 4じゃだめらしいです。

投稿者: こじま 日時: 22:40 | パーマリンク | コメント (0) | トラックバック (0)

Rubyのまつもとさん曰く。

あの時にも考えたように「正しいことを指摘されると腹が立つ」というのが一つ。もうひとつは彼の文章にはプログラミングに対する愛が感じられないのがもう一つ。彼自身もプログラミングする人のはずなんだけどな。

Joelの本についての、まつもとさんのコメントです。

まつもとさんのこの文章を読んだ時は、そういわれればそうだけど商品としてのソフトウェアを作っている立場だとJoelのいってることはかなり納得できるんだよなー、でもまつもとさんの気持ちも分かる(気がする)な、くらいで流していました。

そして今日新聞を見ていたら、ハチミツ通信販売の記事がありました。とびきりのおいしさを主張しつつ、蜜切れのいい、ワンタッチキャップという合理性、そして驚きのハチミツパワー、とかいうありがちな煽りにちょっと萎えます。

これだったら、わたしが時々利用しているハチミツ専門店のほうが好ましいよな、と思いつつ広告を眺めていると「当社の工場はISO9001認証工場です」という主張が目に入りました。これがJoelか(←はげしい飛躍)

まつもとさんはいわばハチミツ専門店で、Joelの立場はISOなんとか認定工場を仕切るマネージャ的なのかな、と考えればすっきりするな。街のレストラン対チェーンのファストフードになぞらえるほうが適切かもしれません。ファストフードの料理には愛が感じられないんだぜ。でも確実に一定の品質のものを提供できるよ。

ソフトウェアにおいて、『ハチミツ専門店』はビジネスとしてありうるのでしょうか。あるといいな。

日々組織でソフトウェア商品をつくってるサラリーマンプログラマとしてはJoelに賛同するんだけど、いち個人プログラマとしてはまつもとさんの感覚にくみしたいです。と今思いましたよ。

投稿者: こじま 日時: 23:32 | パーマリンク | コメント (2) | トラックバック (0)