クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

デザインパターンによるJava実践プログラミング [Stephen Stelting, Olav Maassen(著)]

GoFのデザインパターン23種類とその他のパターン数種類が丁寧に説明されています。
分かりやすかったです。
デザインパターンはいい時にはいいんだろうけどコード読みにくくなるなーと思ってしまう。


備忘録として一言ずつ。

Abstract Factoryパターン
工場を入れ替えると生成物も変えられる。
あとからの仕様追加に強いってことだけど、
大抵あとから仕様追加するとインターフェースも変える必要が出てくるから困る。

Builderパターン
生成の順序や条件が複雑なオブジェクトを生成してくれる。
その複雑さをどうにかするべきと思うけど、便利なときもありそう。

Factory Methodパターン
いわゆる工場。

Prototypeパターン
いわゆるコピーコンストラクタ。
これデザインパターンだったのか!

Singletonパターン
これおもしろいよね。
ただのグローバル変数だという人もいるけど。
マルチスレッドでインスタンス生成関数に同時アクセスしたときの対処方法がカオス。

Chain of Responsibilityパターン
自分で処理できないときに次の人に渡す。
こういうの読むのはおもしろいんだけどなー。
実際には条件とか処理内容とかが複合的で単体をリストにしただけでは処理しきれなくなる。

Commandパターン
関数ポインタをオブジェクトにくるんで投げる。
楽しいけどソースコードで処理追えない!

Interpreterパターン
適用範囲がずいぶん限定的。
特殊な言語とかなんらかの記号列、何かの列を解釈するときの方法。
言語に捉われずにとにかく何かの列を解析、と思えば意外と広いのかもしれない。

Iteratorパターン
これも今ではすごく普通なやつ。
対象が順序でも集合でもツリーでも使えるので便利。
とりあえず全部見る、みたいなときにはいい。
けど、配列をインデックス送っていく方がやってることが明示的で好きだなー。
古い考え方なんだろうけど。

Mediatorパターン
いろんなやりとりの間に入って交通整理してくれる。
そもそも交通整理が必要な状況をどうにかしたい。
Mediatorさんが他の全員と結合するのも気になる。

Mementoパターン
状態をまとめてカプセル化して受け渡し、元の状態に戻ったりできるようにする。
ctrl+Zがいかに偉大かということか。
モーメント(瞬間)かと思ってしまう。

Observerパターン
これも各種フレームワークでお馴染みだけど、自分でゼロからなかなか書かない。
ポーリングみたいに無駄がないし、結合が疎になるのもいい。
けどソースコードを追ったときに通知先リストみたいなのがないから分かりにくい。

Stateパターン
状態をクラスにして状態遷移の実装を綺麗にする。
状態によって処理を変えるswitch文が乱立するのを防ぐ。
場合によってはキレイにいきそう。
やってみたい。

Strategyパターン
インターフェースと目的が全く同じで実装(戦略)だけ違う場合に実装をクラスにして分離する。
そもそもそういう場合があんまない。

Visitorパターン
演算方法を演算対象から分離してそれだけでクラスにして切り替えられるようにする。
カプセル化の逆。
あまりピンとこず。

Template Methodパターン
これ知らずに以前やってたけどやめた。
全体の流れを共通化して、そこから呼ばれるそれぞれの処理をサブクラスで実装する。
結局全体の流れが固定されているのでやりたいことができなくなる可能性が高い。
そもそもその共通化はあまり旨味がない。

Adapterパターン
いわゆるラッパー。
やたらとラップしてるコード、あるよね。
と言いつつ、あとでやりたくなること多いから少し余分にやっとくのはいい気もする。
オーバーヘッド気になる。

Bridgeパターン
いわゆるImplのやつ。
実装とインターフェースを分離する。
継承とか関数のオーバーライドとか面倒が増える。
C++的にはprivate変数をヘッダに晒さなくていいのはすごくいい。
private変数のせいでinclude増えたりするし。
一応この本はJavaの本なので関係ないけど。

Compositeパターン
ツリー構造を実現する。
枝と葉を子に持つ親クラス。
一般的なグラフにも使えるはず。

Decoratorパターン
ラッパーみたいに本体をくるんで、機能追加やチューニングをする。
割とよくやることになる。

Facadeパターン
複数のサブシステムの使い方をまとめて1つのインターフェースにする。
便利関数みたいな。
こういうのやりすぎると中身見えづらくなるから迷う。

Flyweightパターン
共有オブジェクトを使ってメモリ使用量や生成時オーバーヘッドを軽量化する。
うまく使えばよさそう。
共有を下手に隠すと面倒なことになりかねないけど。

HOPPパターン
Half-Object Plus Protocolパターン。
いきなりGoFじゃないの来た!
1つのオブジェクトを分割して遠隔地同士で半分ずつ持つ。
ローカルじゃないほうはプロトコルにのっとって通信で取得する。
状況が難しすぎるなー。
遠隔地のオブジェクトを関数呼び出しのインターフェースで呼べるRMIの発展形。

Proxyパターン
おもしろい。
本物と見せかけて偽物なので、重いオブジェクトを必要なときに段階的に生成したり、
アクセス権を制限したり、遠隔地のオブジェクトのインターフェースになったりする。

MVCパターン
ここからGoFじゃないやつ。
MVC来ましたね。
Viewを切り離すのってほんとに大変。

Sessionパターン
いわゆるクッキー。
SessionIDをいかに正しく管理するか。

Worker Threadパターン
いわゆるThreadプール。
前のタスクを処理してたときの情報が中途半端に残らないようにしないといけない。

Callbackパターン
Observerパターンをネットワーク上でやりました、的な。

Successive Updateパターン
サーバーとクライアントの同期方法。
クライアントプル(クライアントでポーリング)か、サーバープッシュか。

Routerパターン
名前のとおりルーター。
ネットワーク上のルーターも経路グラフの更新とかほんと大変そう。

Transactionパターン
操作をAtomicにするための方法。
SQLサーバーみたいなRDBMSでやってるやつ。
コミットとロールバックができればいい。
さらに安全に2相コミットにしてもいい。
どちらにせよcomit中で落ちたら大変だし難しいジャンルだなぁ。


本書の最後はJavaBeansとかSwingとかJavaのフレームワークで使われてるデザインパターンの話だったので、
さらっと読んでおしまい。

あらためて読むとJavaやC#で普通に機能として取り入れられてるデザインパターンも多くて、歴史を感じました。
  1. 2017/08/06(日) 02:32:38|
  2. | トラックバック:0
  3. | コメント:0
<<超ひも理論とはなにか [竹内薫(著)] | ホーム | インターネットプロトコルがわかる [加地真也(著)]>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/383-70e2ae18
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。