Flex、AIR、Java、Androidなど

Posts Tagged ‘デザインパターン

私はAndroidのアプリを作る際にはユーザー用の設定はSharedPreferenceに入れ、Preference用のアクティビティ等とSharedPreferenceのやり取りを専門に行うクラスをSingletonで用意しています。
SharedPreferenceはcontext.getSharedPreferencesで取らなければならないのでSingletonは
private static UserData instance;
private static Context context;

public static synchronized UserData getInstance(Context c)
{
if(instance == null)
{
UserData.context = [...]

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

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分などで回りくどいメソッドを書かなくてもメインクラス内では全て同じ型なのでそれに処理を委譲してやれば良い。

21 1月, 2009

Compositeパターンの理解

Posted by: tachibana In: プログラミング

※この記事は私が本を読み、頭で考えたことを将来完全に理解してから見直して笑ったりするためにそのまま羅列したものです。故に間違った理解や意味不明なこともたくさん出てくると思います。プログラミングを教えるような立場の方には有益かも(笑)?
Compositeパターンの理解
入れ子構造を実装する為のデザインパターン?その入れ子になった構造に登場するモノ全てのスーパークラスとなるクラスを継承させることでメインクラス上では同じものとして扱うこと。
便宜上メソッドはスーパークラス上にて定義し、サブクラスがそれを実装できない場合には抽象メソッドで例外を投げるようにしておく。
定義は状況によって様々らしい。サブクラスで定義することもあれば、例外を投げないようにすることもある。
パターンで説明していることも利点も分かるのだが、「再帰的」という言葉の意味がぼんやりとしか分からん。。
ハノイの塔を使って説明されていた。
ハノイの塔の解法は理解できるが、どの部分が再帰なの?
というかここでの「再帰的」の意味は単純にそのアルゴリズム(この場合はフィールドやメソッドの定義といった方が適切か)を定義したものを他のものにも適用できることを言うのか?若しくはモノの中にそのモノがあるような状況?また、モノの階層が増えても簡単に解を出せるような構造のこと?ある親の子が更にその子を子として持つようなことができる構造のこと?
イマイチ分からん。
自分なりの結論:

プロジェクト内にいくつかのクラスから生成されたインスタンスがあるが、場合によってはそれらを周りから見て同じもの(厳密には等しくない)として見たいと思うときがある。そのような時には両方に同じ抽象クラスを継承させ、その型でメインクラスに組み込む。こうすることで同じように扱うようにできるが、モノによって実装するメソッドが変わってくるので実装が不可能な時は例外を投げるようにするなどして対策が必要。

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

Categories

 

2017年2月
« 4月    
 12345
6789101112
13141516171819
20212223242526
2728  

About

Author: tachibana

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

Alternative content here