OOD - たまにっき。
2005-08-12 Fri
■ 検索結果を Iterator で返す?
検索結果が Iterator というのが激しく気持ち悪い．
「デザインパターン入門」に合わせて、本の例を示そう。数十万冊の本を持つ図書館データベースを考える。ここで、ユーザがある条件で本を検索したとしよう。例えば、著者が「鈴木太郎」の本、といった具合である。検索結果は、どのように返すべきであろうか？
検索された本のインスタンスをすべて生成してから、その集合を一度に返す、という仕様でも良いのであれば、Iteratorパターンを使う必要はない。しかし、この仕様には、次のような問題がある。
* すべての結果が揃うまで、結果が返されない。最悪の場合、数十万冊の本の照合がすべて完了するまで、数時間かかる可能性もある。
* 検索された本の冊数が多い場合、返される結果が巨大になる。最悪の場合、メモリ上に収まらない可能性もある。
このようなケースでは、Iteratorパターンを使うべきである。検索結果として、本の集合ではなく、Iteratorを返すのだ。
なぜ Proxy パターンを使わない!?
検索した結果に対しては、本の情報を参照することしかさせない、という意図を示すために、検索結果はBookShelfクラスではなく、Iteratorとして返すようにするのである。
検索結果は Immutable であるべきだが，Iterator を返すのは意味が違ってくるでしょう．
]
2005-07-05 Tue
■ Flyweight パターン
Flyweight パターンってボクシングのフライ級のことで，最も体重が軽い階級であると説明されているが，違うじゃないか!!
の説明を鵜呑みにしているんだろうな．
]
2005-05-23 Mon
■ デザインパターンを読み解く
GoFの23パターンをそのまま解説している本が多く、事細かな制約があるかのように見えるせいか、かえって本質が捉えづらくなっている印象があります。23パターンがすべてではないし、このパターン自体パターンが言われ始めた初期に出されたもので、洗練されていないと思うのです。
そうなんだよなー．理解する過程でこれが本質なんじゃないの? とか思っても，どのページを見ても，どの本を読んでも「それが良い」とか「間違っている」と言っていない．単に原典をなぞっているだけのような気がしていた．
例えば，Chain of Responsibility パターンというのは，複数のサブクラスに対して順に処理を依頼するものが本質だと私は考えている．だから，Handler が next を持つ必要もないと思う．どちらかと言えば Handler が next を持ってしまうと，処理のみを行なうべきクラスに構造をも持たせてしまうことになるので，美しくないと思う．
他にも，Singleton の本質は，作成されるオブジェクトの数を限定することだと思っているのだが，ほとんどの紹介文では「オブジェクトをただ一つだけしか生成しないことを保証するものです」としか言われていない．
と，色々と思うことがあるのだが，これをいざ大学2年の学生に教えようと思ってもなかなか難しいんだよなぁ．教科書に書いてあることを否定しているように受けとる学生もいるだろうし，こっちの言葉不足も否定できない・・・．
]
2005-05-05 Thu
■ デザインパターン紹介 ―GoF以外のパターンを紹介します―
Hook Operation パターン みたいなん探してたよ．
]
2005-02-16 Wed
■ 最近プログラミングより，設計の方が楽しく思える．
ほとんど自画自賛の世界なんだが，
俺ってすげぇ．なんでこんな設計を思いつくんだ!?
的なデザインのネ申の降臨を感じるのが楽しいんだろうと自己評価してみる．
]
2004-06-23 Wed
■ モデリングの神さまが降りてくる瞬間
「この関数のこの辺がちょっとくさいな」と先輩プログラマがいってい
るとき、おそらく彼は本当に「におい」をかぎ取っているのだ。そうい
う人にとって、UMLなどという記法は小うるさいだけのものに思えるの
かもしれない。
「だから使わない」と言うヤツがもし，いるのならば，そいつは使えないヤツなんだろうな．
]
2004-04-28 Wed
■ メタクラス
+---------------+
| <<metaclass>> |
| String |
+---------------+
↓インスタンス化
+---------------+
| String |
+---------------+
↓インスタンス化
+---------------+
| abc:String | ← String クラスのインスタンス
+---------------+
メタクラスをインスタンス化するとクラスが得られる。
クラスをインスタンス化するとオブジェクトが得られる。
んでもって、メタクラスは何から作られるかというとメタメタクラスというものがあったりする。
実はメタクラスのメタクラスはメタメタクラスであり、
メタメタクラスはメタクラスをインスタンス化したものであったりする。
鶏が先か卵が先かという問題になったりする。
実際の実装では途中までメタクラスを構築し、それを元にメタメタクラスを部分的に
構築して、そして、メタクラスを作ったりしているみたい。この辺りは怪しい。
ちなみに抽象クラスとは全く異なる概念。
+--------------+
| <<abstract>> |
| List |
+--------------+
△
|
|------------------+
| |
+--------------+ +------------+
| ArrayList | | LinkedList |
+--------------+ +------------+
この図での List が抽象クラスで上のメタクラスの図における String に相当する。
]
2004-01-23 Fri
■ クラス設計に関するメモ
via わんこ日記
だいたい私の設計方針と同じかな．
私は極論として，「継承は使うな」と言うけど．
# もちろん，Servlet や Action など使うべきところでは使わなきゃいかんけど．
Singleton の弊害に色々と書いてあるが，
副作用のある操作を Singleton に対して行うことが，
基本的にはダメだと思うんだがなぁ．
Singleton パターンは最近使ってないなぁ．
Calendar クラスみたいな使い方は良くするけど．
Calendar#getInstance は Calendar のサブクラスである GregorianCalendar を
作って返すような感じの処理．
]
2003-08-09 Sat
■ 「構造」を見る人と見ない人
<http://amrita.s14.xrea.com/d/?date=20030804#p04>
via <http://cgi14.plala.or.jp/imaishi/changelog/2003-08-08.html#2003-08-08-1>
言っていることが良くわからないんだが、かなりの疑問が浮かぶので、とりあえず反論してみる。
私の勘違いもあるかもしれない。
まず、疑問から。
プログラム言語と論理マークアップの違いを自転車と自動車の違いで例えているのが無理があると思う。
自転車と自動車はどちらも移動する目的のための道具であり、同じ目的であるのに対し、
プログラム言語と論理マークアップ言語は目的が全く違う。
自転車と自動車の例を出すならコンパイル言語とスクリプト言語の違いだろうか。
プログラム言語と論理マークアップ言語の例としては自転車と
サイクリングマシン(ジムにあるような動かずに運動するヤツ)だろう。
そして、「見えないものの本質的な構造」を意識する必要があるのは、
オブジェクト指向プログラミングや論理マークアップ言語ではなく、
オブジェクト指向設計であり、論理的考察による理論の展開だ。
ここまで考えて、ようやく言いたいことが見えてきた。
プログラミングの本質(プログラムの設計: 参照元の言うオブジェクト指向言語)や
文章で何がいいたいか(参照元の言う論理マークアップ: HTML の b にするか、strong にするか)を見るか、
プログラムの書き方や文章の書き方を見るかということだろう。
元記事で言いたいことは、昨今、オブジェクト指向が叫ばれているが、
オブジェクト指向での振舞いのみを重点的に見て、何を目的にプログラムしているのかが
わからないという人たちにもオブジェクト指向という聞こえの良さだけで
普及させるのはどうなのか、ということだろう。
で、私の反論としては、
そんなに考えても普及しているという現実を見ればある程度は仕方ない部分もあるでしょう。
現実として、2 カ月程度、新入社員研修で Java の書き方を学んで実践ということもある。
そして、その新入社員として入ってきた人間の上に立つ者も、オブジェクト指向を学んだわけでもなく、
今までのオブジェクト指向でない考え方でやってきた人たちが会社などの意向で
急にオブジェクト指向をやるハメになったということも考えられるし、
実際にそのような現場に直面したこともある。
これに関してはその会社の方針もあるので、第 3 者がとやかく言うことではない。
そのことを嘆いても仕方ない。形から入るのは誰しもやることだと思うので、そのことを責めても仕方ない。
それよりも、本質を理解せずに、その言語や考え方を理解したと思わせることが問題なわけで、
それをなくさせることが大事なんじゃないかな。
例えば、巷に氾濫している入門書がこの場合の問題の部分だと思う(もちろん、中には良い入門書もある)。
それにオブジェクト指向の概念は今に始まったことではない。
例えば、C 言語の fopen とか、fclose はオブジェクト指向的な考えで作られたと思う。
言語がサポートしていないという制限もあるが、ちゃんとオブジェクト指向していると思う。
<http://www.rubyist.net/~matz/?date=20030730#p01>
にもある通り。
私の結論としては、
元の記事は例の出し方はまずかったと思うが、言いたいことはわかるし、共感する。
ただ、上記で書いたように問題としている箇所が私とは異なる。
という私の意見です。
]
2003-04-17 Thu
■ GoF 設計パターン名一覧
Abstract Factory
Adapter
Bridge
Builder
Chain of Responsibility
Command
Composite
Decorator
Facade
Factory Method
Flyweight
Interpreter
Iterator
Mediator
Memento
Observer
Prototype
Proxy
Singleton
State
Strategy
Template Method
Visitor
うーん、実際に使っているのって、10 もないな。
もっと勉強しなければ。
]
2003-02-25 Tue
Powered by 
