問題タブ [flyweight-pattern]

私は Python を学んでおり、パターンの知識を更新する良い言い訳になると思いました。その場合は、Flyweight パターンです。

私は 2 つの小さなプログラムを作成しました。1 つは最適化されておらず、もう 1 つは Flyweight パターンを実装しています。テスト目的で、1'000'000個のEnemyオブジェクトの軍隊を作成しています。各敵には 3 つのタイプ (ソルジャー、ニンジャ、チーフ) があり、各タイプにモットーを割り当てます。

私が確認したいのは、最適化されていないプログラムを使用すると、1'000'000 の敵が、それぞれのタイプと、モットーを含む「長い」文字列を持つことです。EnemyType最適化されたコードを使用して、各タイプに一致し、モットーの文字列の 3 倍だけを含むオブジェクト ( ) を 3 つだけ作成したいと思います。Enemy次に、目的の を指すメンバーを each に追加しますEnemyType。

コード（抜粋のみ）：

1. 最適化されていないプログラム

   このバージョンでは、各敵はそのタイプとモットーを保存します。

   /li>

2. 最適化されたプログラム

   このバージョンでは、各敵は、EnemyTypeそのタイプとモットーを格納するオブジェクトのメンバーを持っています。の 3 つのインスタンスのみEnemyTypeが作成され、メモリ フットプリントに影響が見られるはずです。

   /li>

今、私はこれを使用してメモリフットプリントを取得しています(アプリケーションが閉じる前の最後の行で):

私の問題は、2 つのプログラムの出力に違いが見られないことです。

最適化 = 384.0859375 Mb
最適化なし = 383.40234375 Mb

メモリフットプリントを取得するための適切なツールですか? 私はPythonを初めて使用するので、コードに問題がある可能性がありますが、2番目のソリューションでEnemyTypeオブジェクトをチェックしましたが、実際には3回しか発生していません。したがって、1'000'000 ではなく 3 つのモットー ストリングを使用する必要があります。

Heapy for Pythonというツールについて読んだことがありますが、こちらの方が正確でしょうか?

次のコードを検討してください。

だから私はPersonコンストラクタを

staticReligion*の「テーブル」を検索します。結局のところ、まったく同じ宗派に属する 2 人は同じReligion*価値を共有する必要があります。これが、私がここで実装しようとしているフライ級デザイン パターンです。問題は、パックが長い間わからないことIs...です（サブサブ...デノミネーションの数はどこにも固定されていません）ので、単純な多次元配列は機能しません。代わりに、私がやっていることは、Religion*s のいくつかの静的 const ベクトルを適切なクラスに配置することであり、Is...パックはルックアップする最終的なベクトルを見つけるために使用されます。

更新:これを行うためのより良い方法はありますか? 以下に示すように、これまでに見つけたソリューションには大きな欠点があります。

私はデザインパターンを学び始めます。プロトタイプは私がすでに持っているオブジェクトの正確なコピーを作成するためのものであり、Flyweight は同様のオブジェクトを作成するためのものであることを理解しています。

マリオのような 2D プラットフォーマー ゲームを (Java で) プログラミングしました。位置が違うだけで同じ敵がたくさんい[x,y]ます。膨大な数の長方形から構築された壁もあり、ここでも唯一の違いはそれらの位置[x,y]です。

この特定の状況でこれらの設計パターンのいくつかを使用するのは賢明でしょうか? プロトタイプを使用して cloneable を介してオブジェクトを複製し、次に set を使用する必要があります[x,y]か?

flyweight を使用する方が良いですか? 新しいオブジェクトが必要な場合は、ハッシュマップからそれらを返し、[x,y] を設定するだけですか?

どちらのシナリオでも、新しい演算子の使用は避けていますが、どちらを使用すればよいかわかりません。

Spring を使用しない Java プログラミングで Flyweight パターンを実装しています。これをSpringマネージドBeanにする方法を提案してください。静的メソッド呼び出しと内部クラスがあります。目的は、最初に CRM からすべての OptionSet をロードして、アプリケーションで同じ OptionSet を共有することです。これにより、CRM への高価な呼び出しが防止されます。ユーザーは新しい OptionSet を作成することが制限されているため、内部クラスです。最初に Spring Bean として実装し、それを ApplicationContextAware にして他の Bean を参照する必要があります。私は主に Bean 定義に Spring XML 構成を使用しています。

Prototype DP と Flyweight DP のいくつかの違いを見つける必要があります。基本的な違いは、前者がディープ コピーを作成することです。一方、文字は共有オブジェクトになります。私の講師は、もっと違いがあると言いました。

誰か他の人を知っていますか？

flyweight パターンを適用するには、Object プロパティを組み込みプロパティと外部プロパティに分割する必要があります。組み込みプロパティはオブジェクトを一意にしますが、外部プロパティはクライアント コードによって設定され、さまざまな操作を実行するために使用されます。

しかし、私の質問は、組み込みプロパティと外部プロパティの両方をインスタンス変数として持つことができず (以下の Email クラスを参照)、ループの外側で 1 つのオブジェクトを作成し、ループ内でパラメーターを設定して、異なるパラメーターで複数の電子メールを送信できない理由です。

私には奇妙な状況があります。

オブジェクトのグラフで equal() であるインスタンスを再利用できる単純な flyweight ファクトリがあります。

flyweight を使用して、または使用せずにルート オブジェクトをシリアル化してその利点を測定すると、参照ごとに新しいオブジェクトを含む 2,014,169 バイトから 1,680,865 バイトに減少します。大丈夫です。

しかし、jvisualvm のヒープ ダンプでこのオブジェクトの保持サイズを見ると、常に 6,807,832 と表示されます。

どうしてですか？確かに、あるケースで同じオブジェクトの複数のインスタンスがある場合、それらはそれぞれメモリを占有します。保持サイズは、GC から回収される量である必要があります。flyweight factory を使用してインスタンスをリサイクルしなければ、それ以上になると思います。シリアライゼーションのメリットが見られない場合は、フライウェイト ファクトリのバグだと思いますが、シリアライゼーションでのみ機能する方法がわかりません。

今、私は少し困惑しています。

flyweight ファクトリを使用して、新しいインスタンスをチェックに渡し、代わりに参照を再利用できるかどうかを確認します。

flyweight を使用しない場合は、毎回新しいオブジェクトを保存します。

参考までに、flyweight ファクトリ クラスを次に示します。