Flex、AIR、Java、Androidなど

Archive for 1月 23rd, 2009

Mementoパターン - 自分なりの結論:

あるプロジェクト内で何度も状態が変化するようなインスタンスがある場合、それの状態を保持しておいて利用できるようにしようというのがMementoパターン。保持を行うクラスのフィールドのアクセス修飾子は何もつけず同じパッケージ内のみからのアクセスを通すようにする。また、コンストラクタも同じくアクセス修飾子を省略してパッケージの外からはnewできないようにしておく。パッケージ内にはその状態保持クラスと保持される値を持つオブジェクトしか置かないようにすればフィールドはprivateにしなくても直接アクセスしてやって問題ない。オブジェクトに何らかの状態の変化があり、それを任意のタイミングで状態保持クラスに変更を保存するようにすれば、それから何度か状態が変化したとしても状態保持クラスに残っている値をもとに復元したりすることも可能になる。値を上書きするのではなく配列に入れたりすることでさらに高度なことも可能となる。

Stateパターン - 自分なりの結論:

イベントを起こし得る複数のオブジェクトがあり、それらがイベントを起こしたときにある条件によって処理を分けたいような時、アクション毎にif文とかを書いてはいけない。「ある状態」を表すクラスを作るべきである。Stateパターンを利用する。イベントはdispatchされると状態を表すクラスの親クラスのメソッドを呼ぶだけで、実際にその時にどのように条件により仕訳されているかは知らない。ともかく状態により親クラス型の変数はいくつかのそのサブクラスのインスタンスであるのは間違いないので分岐がスッキリし、管理しやすくなる。

Flyweightパターン - 自分なりの結論:

Prototypeパターンとの違いが分からん。

コメントは受け付けていません。

Fecadeパターン - 自分なりの結論:

これまでもやってきた通り、プロジェクト内では常にクラス同士の結び付けを出来るだけ弱めたり、再利用されたり一部だけの実装を回りに影響が無く出来るようにすることが求められる。Facadeパターンはメインクラスが行いたい処理を可能な限りそのクラスの中で処理し、メインクラスの負担を下げるような働きをする。これにより更に大きなプロジェクトになった際に組み合わせて威力を発揮するパターンのようなもの。「窓口」となるような役を作ること。

Mediatorパターン - 自分なりの結論:

オブジェクトがあるプロパティを持ち、そのプロパティが変化すると他のオブジェクトのプロパティも変化するようなケースに使う。相互に影響するような関係の場合、何も考えずにプロパティが変われば他のオブジェクトのメソッドを呼びプロパティを変更するようなプログラムを書いてはならない。自分のプロパティによって他のオブジェクトのプロパティを変えるような処理を行うことのあるクラスは、初期化されると同時に状態の変化を管理するクラスを保持し状態の変化は条件の分岐も含めその管理クラスに委譲する(どのオブジェクトのどのプロパティがどうなっていればどのオブジェクトの状態をどうするというような処理も全てこのクラスが行う)。これがMediatorパターン。

Observerパターン - 自分なりの結論:

何らかの機能を持つクラス階層があり、その状態の変化などイベント?を監視したい際、同じく監視するだけが目的のObserver的な階層をつくること。実装のクラスも同様に階層を成すが、メインクラス上では通知は実装のトップに行われる(ように見える)。機能のクラスは他のオブジェクトから渡されたObserverを格納するメソッド、削除するメソッドをスーパークラスが実装している為、サブクラスも自動的にObserverの追加・削除できるようになる。また、Observerに通知するメソッドは抽象でないメソッドとしてスーパークラスに定義される為、メインクラスは機能のクラスをインスタンス化した後、Observerを追加してやってから処理に移る。

コメントは受け付けていません。

Decoratorパターン - 自分なりの結論:

Compositパターンにあったように、最終的に何らかのオブジェクトを作りたいときその部品となるものを同じものとして捉えられるよう準備しておく。メインクラスからオブジェクトを生成する際は部品は何種類も存在でき、それら全てが継承元のスーパークラス型にキャストが可能な為、自由な組み合わせや部品に部品を組み合わせたものはオブジェクトでもあり部品でもある(組み合わせ前と型は変わっていない)。この場合は継承でなく委譲を使うこと。

Chain of Responsibilityパターン - 自分なりの結論:

一つのオブジェクトの処理を行う時、このクラスで処理できれば処理し返す、出来なければ次のクラスへ。というような場合はChain of responsibilityパターンで処理する。例によって処理を行うクラスはある抽象クラスを継承していて、それぞれが処理できなければ次はどのクラスに回すかという値を保持するフィールドを持つ。こうすることによりわざわざif分などで回りくどいメソッドを書かなくてもメインクラス内では全て同じ型なのでそれに処理を委譲してやれば良い。

23 1月, 2009

結局アレ買いました。

Posted by: tachibana In: 未分類

KOGAN Agoraが発売無期延期になってからそのむしゃくしゃを晴らそうとして色々考えましたよ。
源泉徴収でお小遣いが少し増えたのもあり、5800XM見てみたり、Mac mini買おうとしたり、ホームシアターセット見てみたり、N97まで待ってみようかと考えたり。
ですがやはり一番面白そうで、弄ってみたいのはアレなんですよね。
また、搭載される予定のFlashはFlash liteベースではなくFlash player 10ベースだそうな。もう買うしかないでしょ。
まあ遊びながらスキルアップにも繋がるでしょうし、弄り倒したいと思います。
到着は遅くても1週間後位でしょうか。

コメントは受け付けていません。

Categories

 

2009年1月
« 1月   2月 »
 1234
567891011
12131415161718
19202122232425
262728293031  

About

Author: tachibana

  • ちょっとしたことはTwitterに書いています。こっちはアプリの公開等の時に更新されます。
  • 最近はもっぱらJavaとObjective Cです。AS3は飽きました。
  • スクリプト言語ではPerlが好きでしたが最近はGAE/Jで何でもやってます。
  • Linuxは自宅サーバー建てるのがやっとのレベルです。前の会社で何日も徹夜してやったのはいい思い出です。
  • アプリへのご要望などご意見等ありましたらお気軽にご連絡下さい。

Alternative content here