Study / Design pattern 検索結果

検索件数 : 19

1

こんにちは。明月です。この投稿はデザインパターンのステートパターン(state pattern)に関する説明です。ステートという意味では状態です。つまり、クラスの状態により処理する結果が別々になる意味です。よく見るとストラテジーパターンと似ている構造になりますが。。。差異を置いたらストラテジーパターンはストラテジーインスタンスにより外部の値が変わることだし、ステートパターンはステートインスタンスにより内部の値が変わることだと思います。実は、デザインパターンというのは実務でこれはこのパターンという定義されていることではなく、その内容だけ理解して使ったら良いでしょう。reference - https://en.wikipedia.org/wiki/state_patternストラテジーパターンには多分、run関数に何かの値を受け取ります。つまり、run関数で値を受け取ってストラテジーパターンにより別の値がリターンすることだし、ステートパターンはrunの関数で値を受け取ることではないですが、ステートインスタンスにより内部処理が変わったということです。私が知っているストラテジーパターンとステートパターンの差異はこれです。実は私も実務でストラテジーパターン、ステートパターンを区切りして使うことではありません。ただ仕様に合わせてパターンを使うことで。。ステートパターンもストラテジーパターンと同じ構造でflyweightパターンを使ってステートパターンのインスタンス生成を最小化にしました。そしてインスタンスの再使用率を高めにしてシステムの性能を上げられます。ステートパターンもストラテジーパターンと同じ目的で使います。クラスの結合度を低くして再使用率を高めにするために使うでしょう。ただ、その差異はストラテジーパターンは外部の値がパターンにより別々の結果を出すこと、ステートパターンはパターンにより内部値が別々の結果を出すことです。ここまでデザインパターンのステートパターン(state pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#statepattern

作成日付 : 2021/11/17 20:04:47       修正日付 : 2021/11/17 20:05:36

2

こんにちは。明月です。この投稿はデザインパターンのメメントパターン(memento pattern)に関する説明です。メメントパターンはクラスの現在の状況を別にクラスに格納するパターンです。クラスのデータを格納する型ではメメントパターンではなく、クラスのコピー(インスタンスのコピー)で現在状況を格納することができます。でも、そのようにすると現在のインスタンスオブジェクトではなく、新しいインスタンスオブジェクトを生成することで、もしオブジェクト中でリソース(ioやsocket)を使っている場合は新しいコネクションを生成しなければならない問題もあります。つまり、メメントパターンはインスタンスのオブジェクトは変わらず、中の値だけ更新して、状態を復旧する役割をするパターンがメメントパターンです。reference - https://en.wikipedia.org/wiki/memento_pattern上の例でnodeクラスの状態を格納するmementoインスタンスを取得しました。このmementoクラスで該当なクラスをファイルに書き出しするし、また、ファイルから読み込んでnodeインスタンスに更新するとデータが以前データに復旧することを確認できます。例えば、ゲームの中でファイルにセーブしてまたファイルから読み込んで現在の状態を復旧することと同じ流れのパターンです。c/c++で作成したソースの構造と似ています。ただ、memenoクラスをnodeクラスのインラインで作成しました。つまり、mementoクラスの仕様は状態を格納する役割があるので、nodeクラスの以外ではデータ設定ができないようにすることが基本ルールです。メメントのインスタンスの値を外部で設定することが可能にすると、それはメメントのパターンではなく、単純なパラメータをやり取りのクラスの役割になることです。c#もjavaと似ている構造なソースです。mementoクラスがnodeクラスにインラインで設定して、nodeクラスの外部では設定できないように作成しました。でも、c#はインラインクラスでも、publicではなければアクセスができないので、reflectionの機能を利用して直接にprivate変数を設定できるように作成しました。ここまでデザインパターンのメメントパターン(memento pattern)に関する説明でした。ご不明なところや間違いと

Study / Design pattern

#designpattern,#mementopattern

作成日付 : 2021/11/16 20:01:36       修正日付 : 2021/11/16 20:02:25

3

こんにちは。明月です。この投稿はデザインパターンのイテレータパターン(iterator pattern)に関する説明です。イテレータパターン(iterator pattern)は我々がデザインパターンを知らない状況でもよく使うパターンです。c#にはlistをforeachで使うパターンだし、javaにはfor(var x : list)の型でよく使うパターンです。一般的に配列(array)には当たり前にindexで配列を参照するのでイテレータパターンが意味がありませんが、連結リスト(linkedlist)なら話が違います。get(100)を取得するためにはindex 0から100まで移動するので実際にforで使うことならすごく遅くなります。例えば、0番目はリストの最初なので問題がありませんが、forの1になると0を参照して1番目を取得します。また、2になると0を参照して1に移動、2を取得します。3になると0を参照して1に移動、2に移動して3を取得します。なのでイテレータパターンを利用して毎回に参照するたびにポインタを移動して探す必要がなしで現在の位置を格納して現在の値をリターン、そして次のポインタに移動する型のパターンが必要です。実務ではこれを実装する必要がなしで、listタイプはすべてイテレータパターンを継承しているのでforeachで使ったら自動にイテレータパターン(iterator pattern)に変わるにで、ただこのパターンの内容だけ認知して応用して使うと良いでしょう。reference - https://en.wikipedia.org/wiki/iterator_pattern我々が実際にプログラムで使うイテレータパターンはforを利用して値のポインタを取得、一連の順番とおりに出力するパターンです。実は私がc/c++でイテレータパターンを実装しようと思いましたが、難しいですね。c/c++を使うのも古くなったし、いざ実装するのが簡単ではありません。それでここではただイテレータパターンを使う方法だけ説明します。もし、イテレータパターンを実装する人がいらっしゃいならお知らせてください。上の例は簡単な連結リストのアルゴリズムです。そして任意で連結リストのlinkedlistクラスをforの繰り返し文にイテレータパターン(iterator pattern)でデータが順番とおりに出力されることを確認で

Study / Design pattern

#designpattern,#iteratorpattern

作成日付 : 2021/11/15 19:31:28       修正日付 : 2021/11/15 19:32:13

4

こんにちは。明月です。この投稿はデザインパターンのコマンドパターン(command pattern)に関する説明です。コマンドパターン(command pattern)は少し複雑なパターンですが、簡単に言うと発動子(invoker)が受信子(receiver)を実行するためのコマンド(command)を中に置くパターンです。普通のコマンドパターンの例なら電灯の例で説明しますが、スウィッチ(invoker)があり、電灯(receiver)があります、それを電源のonとoffのコマンド(command)が型です。reference - https://en.wikipedia.org/wiki/command_pattern上の例をみると理解しやすくなります。コマンドパターンは発動子(invoker)の関数をクラス別に分け割ったことです。関数はインスタンスで実装することができないので、関数別でインスタンスを作った型がコマンドパターン(command pattern)です。関数をクラスのインスタンスで生成ができれば、上みたいにlistなどで命令順番を設定することもできます。コマンドパターンは重要なポイントは発動子(invoker)の関数をクラス別で割り分けしたことです。つまり、様々な関数を複合的にコマンドパターンで作成することができます。ここでの例は発動子(invoker)のクラスを一つだけ生成してコマンドパターンを作りましたが、数多く発動子クラスをコマンドパターン別で割り分けてストラテジーパターンとともに使うことができます。ここまでデザインパターンのコマンドパターン(command pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#commandpattern

作成日付 : 2021/11/05 17:01:42       修正日付 : 2021/11/05 17:02:32

5

こんにちは。明月です。この投稿はデザインパターンの責任の連鎖パターン(chain of responsibility pattern)に関する説明です。責任の連鎖パターンとはクラス間に連結リストアルゴリズムを掛けて、特定な関数を実行すると連鎖的に実行するパターンということです。reference - https://en.wikipedia.org/wiki/chain-of-responsibility_patternこれがすごくよく使うパターンではないですが、ログ処理や一つの処理で様々な結果を同時に作成する時に使うパターンです。ソースコードを作成したら完全に連結リストのアルゴリズムになりました。連結リストのアルゴリズムをよく知っている方はよく目に入れると思いますが、アルゴリズムの分野が弱い方はすごく複雑に見える可能性がありますね。内容は私がloggermanagerにconsoleloggerとfileloggerのインスタンスを格納しました。そしてwrite関数を呼び出したら順番とおりにコンソールに出力されますね。つまり、setloggerの関数でインスタンスを格納した数程、write関数で連鎖的に出力するパターンです。javaには連結リストのlinkedlistクラスがあります。つまり、javaには連結リストが実装されているのでそれを使ったら良いでしょう。もちろん、必ずlinkedlistを使う必要なく、arraylistでも構いません。つまり、責任の連鎖パターン(chain of responsibility pattern)はポインターで連結すると言いますが、c/c++にもvectorオブジェクトを使っても実装することでは問題ないでしょう。loggermanagerというクラスが必要なく、loggerクラスに次のポインタを連結して最初に生成されたインスタンスの関数を呼び出すと連鎖的に実行する方法もあります。責任の連鎖パターンはクラスの結合度を弱くして様々な応用にかなり良いパターンですが、以外に使用頻度が低いパターンです。適応する仕様が多くないからではないかな。ほとんどファサードパターンとストラテジーパターンで解決される仕様が多いからかなここまでデザインパターンの責任の連鎖パターン(chain of responsibility pattern)に関する説明でした。ご不明なところや間違いところが

Study / Design pattern

#designpattern,#chainofresponsibility

作成日付 : 2021/11/04 19:27:58       修正日付 : 2021/11/04 19:28:32

6

こんにちは。明月です。この投稿はデザインパターンのストラテジーパターン(strategy pattern)に関する説明です。この投稿からは振り舞パターンに関する説明です。生成パターンはプログラムでインスタンスをどのように生成するかに関する型だし、構造パターンはインターフェースと抽象クラス、そして一般クラス間の構造的な定義に関する型です。振り舞パターンはクラスとアルゴリズムを実際のプログラムでどのように使うかに関する説明するパターンです。その中でストラテジーパターンは戦略という意味があるパターンですが、使うクラスに入力されるクラスのインスタンスにタイプにより結果を別にするパターンと言います。reference - https://en.wikipedia.org/wiki/strategy_patternすごく単純な構造です。processクラスにストラテジーパターンを設定しなければそのまま10の値が出力されるし、normalstrategyインスタンスを入力すると100の値が出力、specialstrategyインスタンスを入力すると1000が出力されます。仕様に違いますが、ストラテジーパターンのクラスをフライウェイトパターンと一緒に使えばクラスの再使用率が高めるし、性能改善にもいい利点があります。上の例はストラテジーパターンにflyweightパターンを追加してストラテジーパターンのインスタンスを取得する時、メモリ使用を最小にしてクラスの再使用率を高めにしました。ストラテジーパターンはできればクラスの結合度を低くして再使用率を高めにして性能改善がメイン目標です。そしてクラスはできれば分ける作業によりプログラムのutテストや個別テストが良いと利点があります。でも、このストラテジーパターンの欠点はクラスを分けすぎることでストラテジーパターンで分散化すると可読性が悪くなることがあります。そしてクラス作成が多くなるので、プロジェクト管理が難しくなるし、プロジェクト難易度が高くなる問題があります。ここまでデザインパターンのストラテジーパターン(strategy pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#strategypattern

作成日付 : 2021/11/03 18:38:52       修正日付 : 2021/11/03 18:38:52

7

こんにちは。明月です。この投稿はファサードパターン(facade pattern)に関する説明です。ファサードパターンはデザインパターンで一番よく使うパターンの中で、我々がデザインパターンを知らなくても自然に使うパターンではないかと思います。このパターンを簡単に説明すると以前に生成されたオブジェクトや関数を仕様により合わせて配置する構造です。reference - https://en.wikipedia.org/wiki/facade_pattern上の例を説明すると、main関数には、ファサードパターンのクラスで設定したrunaやrunb関数を実行することで、仕様により順番とおりに実行する構造です。つまり、facadeクラスには処理する順番を設定して、main関数にはruna関数を呼び出すことで処理が開始される型の構造になっています。ファサードパターンだっても別にクラスを生成する必要はなくて、controllerの型でオブジェクトの各処理はprivateで処理して、クラスの外部ではファサードパターンでアクセスが可能にするようにexectype1関数やexectype2関数みたいに作成することが一般的ですね。実務でよく使うファサードパターンで例を作成しました。実は上にはファサードパターンだけではなく、interpreterパターンも含めています。main関数には我々がwebでよく使うurlの値を入れました。実は文字列切りは正規表現式を利用して切り分けるべきですが、個人的に正規表現式が得意な分野でもないし、面倒なのでただsplitで切り分けました。つまり、mvcモデルで上みたいにウェブブラウザで呼び出すとroute関数を通って関数を探すことになります。そしてパラメータに合わせてパラメータクラスのインスタンスも生成して呼び出しすることになります。我々はそのfacadeパターンで作成されているフレームワークで要請メソッドだけ作成すればよいでしょう。つまり、フレームワークのmvc構造はfacadeパターンで実装されていることです。実はfacadeパターンはこのパターンを知らなくても、もうプログラムを作成する時によく使う方法ですね。でも、少し理論的なパターン流れを分かれば、上みたいにreflection機能まで追加して応用が可能なパターンを実装することができます。ここまでファサードパターン(facade patt

Study / Design pattern

#designpattern,#facadepattern

作成日付 : 2021/11/02 19:32:31       修正日付 : 2021/11/02 19:32:31

8

こんにちは。明月です。この投稿はデザインパターンのプロキシパターン(proxy pattern)に関する説明です。プロキシパターンはデコレーターパターンと似ているな構造を構成していますが、デコレータパターンは継承したインターフェースでコンストラクタから同じインターフェースを継承したインスタンスを受け取って内容を追加する内容なら、プロキシパターンは継承したインターフェースでクラス内部で同じインターフェースを継承したインスタンスを生成するパターンです。reference - https://en.wikipedia.org/wiki/proxy_pattern上の構造がプロキシパターンの基本構造です。nodeproxyクラスのコンストラクタからinodeインターフェースを継承したnodeクラスのインスタンスを生成します。そしてprint関数にはnodeインスタンスのprint関数を呼び出します。普通はnodeクラスをnodeproxyクラスのインラインクラスに作成する場合もあります。上みたいになぜこのように作成するかと思われますね。ただ、proxyクラスではなく、nodeクラスのインスタンスを生成すればよいのに。。proxyクラスのコンストラクタのパラメータにより内部のメンバー変数のinode nodeに生成されたインスタンスが違います。つまり、パラメータやデータによりインスタンスを区分する時に使うパターンだということです。今回にはnode1クラスとnode2クラスをnodeproxyクラスのインラインクラスに作成しました。そしてインスタンスをコンストラクタから生成することではなく、print関数から生成します。つまり、もしnodeクラスが多いデータを持っていることやリソースを使うクラスなら、上みたいにコンストラクタではなく、関数を呼び出す時にインスタンスを生成することで性能を考えて設計することができる利点もあります。私の考えはパターン構造としては生成パターンのファクトリーメソッドパターンとflyweightパターン、デコレーターパターンをよく使う状況でプロキシパターンがよく使うかなと思うパターンですね。そうからかな、実際によく使うパターンではありません。また、似ている構造でインターフェースを継承せずに、メンバー変数に様々のクラスのインスタンスを入れて使いますね。でも、仕様によりプロキシパターンがもっと最適な

Study / Design pattern

#designpattern,#proxypattern

作成日付 : 2021/11/01 19:42:44       修正日付 : 2021/11/01 19:42:44

9

こんにちは。明月です。この投稿はデザインパターンのフライウェイトパターン(flyweight pattern)に関する説明です。フライウェイトパターン(flyweight pattern)という英語の意味は軽量化するという意味です。なので、インスタンスの生成を最小化してメモリの使用をできれば節約する方法です。構造パターンのシングルトンバージョンだと思えば良いでしょう。でもsingletonみたいにstaticを利用することではなく、普通のmap(dictionary)を利用します。reference - https://en.wikipedia.org/wiki/flyweight_patternbuilderというクラスでgetnodeからnodeインスタンスを取得します。そのことでaのキーで取得した時にはcountが2になりました。その意味はaを二回呼び出しましたが、インスタンスは同じという意味ですね。つまり、二回目から呼び出したらインスタンスを新しく生成しなくて、mapに同じインスタンスを取得することがフライウェイトパターンです。実はフライウェイトパターンは上のファクトリーメソッドパターンとともによく使います。factoryでインスタンスを生成せずに一回生成されたインスタンスは再使用ということです。でも、ファクトリ―メソッドパターンなのでclassを追加するたびにfactory関数を修正しなければならないですね。上のれ例ではjavaの例と似ていますが、factorydao中をreflectionとgeneric機能を利用してインスタンスを取得することにしました。このパターンどのところで使うかと思えば、ormフレームワークのdaoを取得する関数で使う方法です。特にspringで依存性注入でdaoを取得する時に、フレームワークでは上みたいな構造でインスタンスを取得することです。つまり、一回に生成されたインスタンスは再使用しようという意味ですね。ここまでデザインパターンのフライウェイトパターン(flyweight pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#disignpattern,#flyweightpattern

作成日付 : 2021/10/29 19:48:27       修正日付 : 2021/10/29 19:48:27

10

こんにちは。明月です。この投稿はデザインパターンのデコレーターパターン(decorator pattern)に関する説明です。デコレーターという英語の意味では飾るという意味です。その意味でデコレーターパターンはインターフェースから継承したクラスの機能を拡張するためのパターンだと言えます。reference - https://en.wikipedia.org/wiki/decorator_pattern上の例をみると始めのnodeクラスからは単純なnode->print()の出力だけあるでしょう。でも、nodetimedecoratorのデコレーターを追加して、nodelogdecoratorのデコレーターを追加しました。結果はnodelogdecoratorのprintが呼び出してnodetimedecoratorのprintが呼び出して、最終的にnodeクラスのprintが呼び出されました。デコレーター構造は抽象クラスからインターフェースを継承してコンストラクタには継承したインターフェースを継承したインスタンスを受け取ります。そしてデコレーター抽象クラスを継承したクラスにはインターフェースの定義により作成してメンバー変数にある継承したインターフェースのインスタンスを実行します。そうならデコレータークラスはinodeを継承したすべてのインスタンスの抽象化された関数にデータを追加することができます。上の例はデコレーターパターンでファクトリーメソッドパターンを追加したことです。getnodefactory関数でcaltypeタイプのパラメータの結果により取得するインスタンス種類が違いますね。個人的に構造パターンの中でファサードパターン(facade pattern)の以外によく使うパターンではないかと思います。例えば、フレームワークや.net frameworkで提供する基本クラスを仕様により変更することが多いですが、その場合、デコレーターパターンを適用するとすごくコーディングが楽になることを感じますね。特にログ処理クラスやデータベースのデータ処理クラスでよく使います。ここまでデザインパターンのデコレーターパターン(decorator pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#Decoratorpattern

作成日付 : 2021/10/28 20:11:13       修正日付 : 2021/10/28 20:11:13

11

こんにちは。明月です。この投稿はデザインパターンのブリッジパターン(bridge pattern)に関する説明です。ブリッジパターンとは概念として抽象部の処理と実装部の処理を独立的に使えるような方法です。理解しやすく言えば、抽象部は、つまりインターフェースから関数に関する処理を定義すると、継承した実装部、つまり、クラスには受け取ったインスタンスにより別の結果を実装する構造です。reference - https://en.wikipedia.org/wiki/bridge_pattern上の結果をみればbridgeのクラスにどのインスタンスを渡すことにより結果が違います。つまり、node1インスタンスを渡すとnode1の結果がコンソールに出力するし、node2インスタンスを渡すとnode2の結果がコンソールに出力されます。bridgeクラスはinodeクラスの実行に関する定義を実装することでそのデータ値により結果が別々に出力されます。javaの例もc++と似ている構造です。ブリッジパターンはほぼ規格されたパターンかな?別の型で応用しようと思うが、良い例がないですね。私が知らない可能性もあります。このブリッジパターンは我々が良く使うmvc型のフレームワークでよく見えるパターンです。client(browser)から要請が来るとパラメータをmodelクラスにインスタンス生成してcontrollerを呼び出して実際に我々が作成する実装部はcontrollerのexecute関数です。抽象部分はすべてフレームワークで実行されていますね。ここまでデザインパターンのブリッジパターン(bridge pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#bridgepattern

作成日付 : 2021/10/27 20:32:21       修正日付 : 2021/10/27 20:32:21

12

こんにちは。明月です。この投稿はデザインパターンのコンポジットパターン(composite pattern)に関する説明です。コンポジットパターン、合成パターンと呼ばれるパターンです。一つのクラスと複合クラス(つまり、リスト)を同一な構成して使うパターンという意味です。reference - https://en.wikipedia.org/wiki/composite_patternコンポジットパターンの基本的な型です。共通のインターフェースに一つは単一実行に関するインスタンスにprint関数を再定義して、一つは複数のインスタンスに関するprint関数を再定義して実行しました。つまり、コンポジットクラスは同じなインターフェースから継承してリストタイプのメンバー変数を生成し、add関数を通って同じインターフェースを継承したインスタンスを受け取って同じ関数名を実行する型のパターンです。普通はlistをメンバー変数に実装しますが、listを継承して実装することもできます。個人的にlistを継承するほうが別にadd関数やremove関数を実装する必要がなくて便利だと思いますが、仕様によりメンバー変数でlistの関数を隠すことやアダプターパターンで別の型に変換する可能性もあります。一つのクラスに対するパターンではありません。inodeを継承したすべてのインスタンスを同じ構造のcompositeクラスで一括的に実行するための目的です。ここまでデザインパターンのコンポジットパターン(composite pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#compositepattern

作成日付 : 2021/10/27 20:30:54       修正日付 : 2021/10/27 20:30:54

13

こんにちは。明月です。この投稿はデザインパターンのアダプターパターン(adapter pattern)に関する説明です。アダプターパターンからは構造パターンです。構造パターンとは様々なクラスやオブジェクトを組み合わせてもっと大きい構造を作るパターンです。以前の生成パターンはnewキーワードを利用してインスタンスを生成する型がメインだったら、構造パターンはクラスやオブジェクトの構造をどのように構成するかをメインに考えるパターンです。アダプターパターンはインターフェースに連結されてない他のクラスを同じインターフェースの型に変換することが目標です。reference - https://en.wikipedia.org/wiki/adapter_pattern上の例をみれば私がmain関数でinodeインターフェースタイプのインスタンスをvectorを使って格納するため、宣言しました。でも、node2クラスはinodeインターフェースを継承したクラスではないので、inodeインターフェースグループに格納することができません。クラス構造は似てますが。。。node2をinodeから継承したら簡単に解決するかも知れませんが、状況によりnode2クラスを修正したらダメなら上みたいにadapterクラスを作成してnode2クラスをinodeインターフェースから継承したらしく使えます。adapterパターンが必ずクラスだけ使うことではありません。上みたいにinterfaceアダプタークラスを作成してinodeanotherから継承したクラスはinodeインターフェースを化粧したアダプタークラスに変換することが可能です。アダプターパターンは基本的にコンストラクタでタイプを変更しようと思うクラスのインスタンスを受け取って新しいクラスで包むことです。でも、必ずコンストラクタでインスタンスを受け取ることではなく、上みたいに継承を利用してアダプターパターンを実装することができます。ここまでデザインパターンのアダプターパターン(adapter pattern)に関する説明でした。ご不明なところや間違いところがあればコメントしてください。

Study / Design pattern

#designpattern,#adapterpattern

作成日付 : 2021/10/26 19:12:40       修正日付 : 2021/10/26 19:12:40

14

こんにちは。明月です。この投稿はデザインパターンのプロトタイプパターン(prototype pattern)に関する説明です。プロトタイプはパターンのアルゴリズムはすごく単純なパターンですが、概念的にポインターとスタック、ヒープメモリに関する概念をよく知らないなら理解するのが難しいパターンです。我々がプログラム上でクラスのインスタンスを生成すると変数にポインターアドレスが格納されるし、ポインターアドレスによりヒープメモリにインスタンスが割り当てすることです。そのため、変数で新しいインスタンスを生成せずに、等号(equal: =)記号で新しい変数名にインスタンスのアドレスをコピーすると二つの変数で一つのインスタンスを指しているので、変数の間でデータの影響に及ぼします。当たり前の話ですが、当然に影響を及ぼします。結果を見るとnode変数とnodeclone変数のメモリアドレスが同じなことを確認できます。上のイメージみたいな構造で二つの変数に一つのインスタンスを指しているからです。link - [c#] 11. インスタンスう生成(new)とメモリ割り当て(stackメモリとheapメモリ)そしてヌル(null)link - [java] 10. メモリの割り当て(stackメモリとheapメモリ、そしてnew)とcall by reference(ポインタによる参照)そうなら逆にそのインスタンスアドレスをコピーせずに、クラスのデータを同じくしてクラスをコピーすることができないだろうか?上のクラスはすごく単純な構造なのでnew nodeしてdataの値をコピーすることで可能ですが、複雑なクラスだし、メンバー変数がすべてprivateに設定している場合は単純にコピーすることが難しいですね。reference - https://en.wikipedia.org/wiki/prototype_patternc/c++には単純にclone関数で新しいインスタンスを生成するnewキーワードを使ってthisポインターをパラメータに渡すとインスタンスコピーになります。結果を見るとdataの値は同じですが、メモリアドレスが違うことを確認できます。javaの場合はcloneableインターフェースを継承してからプロトタイプ関数のclone関数を使えます。そしてobjectクラスにはclone関数がprotectedのアクセス修

Study / Design pattern

#prototype,#designpattern

作成日付 : 2021/10/22 19:35:45       修正日付 : 2021/10/22 19:35:45

15

こんにちは。明月です。この投稿はデザインパターンの抽象ファクトリーパターン(abstract factory pattern)に関する説明です。デザインパターンの生成パターンの中で一番複雑なパターンの抽象ファクトリーパターン(abstract factory pattern)です。構造は複雑ですが、細かく見るとファクトリーメソッドパターンでファクトリーをクラスで作成してその上に抽象インターフェースによりファクトリーを取得するし、そのファクトリーでクラスを取得する構造です。つまり、ファクトリーメソッドパターンが重畳していると思えば良いです。reference - https://en.wikipedia.org/wiki/abstract_factory_pattern上の例をみればfactoryクラスをgetfactoryという関数からインスタンスを受け取ります。また、factoryクラスにはgettypedaoを通ってインスタンスを受け取ります。私はここでビルドパターンを通ってidaoを受け取りますが、gettypedaoにパラメータを入れてまたファクトリーメソッドパターンを使えます。上の例はjavaで作成した抽象ファクトリーパターン例です。c/c++と違い、ファクトリークラスの中でビルドパターンを代わりにファクトリーメソッドパターンでインスタンスを取得します。上の例はc/c++と同じく、ファクトリークラスでビルドパターンでインスタンスを取得して実行します。私がfactoryクラスではなく、一般クラスをdaoというクラス名で作成しました。なぜならこの抽象ファクトリーパターンがormフレームワークで一番よく使うパターンからです。例えば、データベースの各テーブルのdaoクラスを作成します。でも、仕様によりこれがoracleになれるし、mssqlになれるし、mysql(mariadb)になれる可能性があります。各データベースのシステムのテーブルの設計構造は同じだと思えば、この抽象ファクトリーパターンを使ったらoracle用dao生成ファクトリーを生成することができるし、mssql用dao生成ファクトリーを生成することができます。その以外にデータ管理や生成、pdf生成やexcel生成などで仕様により装置を区分する時、該当なクラスの構造は同じく作ろうと思えば、よく使えるパターンです。ここまでデザインパターンの抽象

Study / Design pattern

#designpattern,#Abstractfactorypattern

作成日付 : 2021/10/15 19:31:03       修正日付 : 2021/10/15 19:31:03

16

こんにちは。明月です。この投稿はデザインパターンのファクトリーメソッドパターン(factory method pattern)に関する説明です。以前の投稿でビルダーパターンに関して説明しました。link - [design pattern] 1-2. ビルダーパターン(builder pattern)ビルダーパターンは簡単に説明するとbuilderクラスとdirectorクラスの組み合いで一つのインスタンスを生成する生成パターンです。このファクトリーメソッドパターンもビルダーパターンと同じ生成パターンの一つで、インスタンスを生成するパターンです。このファクトリーメソッドパターンはメソッドのパラメータにより生成されるインスタンスを変わる形のパターンです。reference - https://en.wikipedia.org/wiki/factory_method_pattern上の例をみればfactory関数のパラメータの値によりnode1クラスのインスタンスを生成するかnode2クラスのインスタンスを生成することが決めます。ビルダーパターンと比べたらすごく簡単な構造です。javaの例ではパラメータの値をstringで受けます。つまり、stringデータによりインスタンスを生成することができます。こんなことになると実際のプロジェクトにはデータベースやユーザから受ける値により生成するインスタンスを変わって実行するロジックを選択することができます。そしてファクトリーメソッドにはリターンするタイプを一つ種類のタイプに統一しなければならないのでinterfaceを使いました。上の例はstringタイプではなく、列挙型の値によりインスタンスを生成しました。stringタイプを使うことはもし、string値にタイプミスがある場合、デバッグ段階でエラーをチェックしないので、バグが発生する可能性があります。でも、列挙型でパラメータを設定すればバグが発生する可能性は少しなくすことができます。ファクトリーメソッドパターンは普通はシングルトンパターンと組み合いしてよく使います。なので、entityタイプのデータクラスよりcontrollerみたいに処理クラスによく使います。上の例はnode1クラスとnode2クラスにあるコンストラクタをprivateに設定してgetinstance関数でインスタンスを取得する形のシングルトンパ

Study / Design pattern

Factory method pattern

作成日付 : 2021/06/23 19:45:37       修正日付 : 2021/06/23 19:46:01

17

こんにちは。明月です。この投稿はデザインパターンのビルダーパターン(builder pattern)に関する説明です。ビルダーパターンとは我々が普通にクラスのインスタンスを生成する時にnewキーワードを使った生成しますが、その方法ではなく、他のクラスを利用してインスタンスを生成するパターンだといいます。そしてインスタンス中でデータを入力するし、そのついて処理関数などを呼び出してクラスのデータを処理する方法です。仕様によって違いますが、クラスの目的があり、初期値及びデータはどのぐらい決まっているし特定なパターンによりクラスのデータを入力する方法で使います。実行関数及びロジック関数でクラスの初期値を入力する方もありますが、その方法は不便なこともあるし、ソース読みにくいです。上のソースが間違っているかエラーが発生するか、パフォーマンスが悪いソースではありません。でも、nodeクラスのインスタンスを生成してメンバー変数にデータを格納する形が少しコードが汚いらしいです。もし、nodeクラスで使う変数が多い状況や、クラスのインスタンスを生成するために処理が多い場合(パラメータデータを作成するための処理)にはそのほどソースの可読性が悪くなります。そうなら、コンストラクタでnodeクラスに必要なパラメータデータを渡したらいいではないかと思いますが、インスタンスを生成して変数値を格納する構造と別に変数を生成して入力してコンストラクタパラメータで渡す構造と結局同じ構造になります。そうならすこしソースを減らすような方法でnode1とnode2の共通インターフェースを作って関数などを通ってインスタンスを生成して受け取ったらソースステップを減らすこともできるし可読性を高められます。上のソースはbuild関数を使ってクラスインスタンスを生成しました。そして始めのパラメータを通ってクラスを区分してインスタンスを生成しました。ロジック流れだけみれば上の例もビルダーパターン(builder pattern)です。でも、build関数をみれば変数設定のために強制キャストしてデータを入力しました。結局、初めの例と差異がありません。正確にビルダーパターン(builder pattern)を実装するためにはパラメータ役のbuilderクラスとbuildを実行するdirectorクラスを通ってデータを設定して最終結果のnodeクラスを受け取ることが

Study / Design pattern

design pattern

作成日付 : 2021/06/11 19:06:28       修正日付 : 2021/06/11 19:07:16

18

こんにちは。明月です。この投稿はデザインパターンのシングルトンパターン(singleton pattern)に関する説明です。シングルトンパターンはデザインパターンの中で一番有名なパターンです。デザインパターンを聞いたことがなくてもシングルトンパターン(singleton pattern)を聞いたことがあるほど有名なパターンです。シングルトンパターンはクラスのインスタンスをプログラム実行中で一回だけ生成して続けて再使用するパターンです。利点ではクラスのデータを変わらずにずっと使うかすべてのオブジェクトからデータを共有しなければならない状況で使います。c/c++例から確認しましょう。シングルトンの特性はコンストラクタをprivateに設定することが重要です。コンストラクタをprivateに設定するとクラス外部からインスタンス生成をできません。そしてクラスのインスタンスはプログラムが終了する時まで保持しなければならないので、staticで宣言してクラス内部で管理します。また、static関数(getinstance())でクラスのインスタンスを生成してsingleton変数に管理すればインスタンスを一回生成して再使用するシングルトンが作られます。上の結果をみればnode1とnode2のメモリアドレスが同じです。つまり、node::getinstance()でインスタンスを取得すれば同じクラスが返却します。javaのシングルトンパターンもコンストラクタをprivateに設定してクラスインスタンスをもっている変数をprivate staticで宣言します。つまり、プログラムが終了する時まで変数のインスタンスが保持されます。javaのhashcodeを出力値をみれば同じ値が出力することを確認できます。つまり、同じクラスという意味です。c#にもコンストラクタをprivateに設定してgetinstance()関数を利用してインスタンスを取得します。結果も同じhashcodeが出力することで同じクラスインスタンスということを確認できます。シングルトンパターンは普通リソースを扱うクラスでよく使います。例えば、file ioや通信socketクラスと共に使います。なぜなら一つのfileを読み込んで書き込むクラスを様々なインスタンスで生成して接続すればconnection errorが発生します。ログシステムがその例です。ロ

Study / Design pattern

作成日付 : 2021/06/09 19:40:05       修正日付 : 2021/06/09 19:41:09

19

こんにちは。明月です。この投稿はデザインパターンの紹介に関する説明です。デザインパターンとは英語でdesignですが、我々が考える画面デザインという意味ではなく、設計の意味です。つまり、設計パターンということです。始めにこのデザインパターンを提案する人はgofと呼ばれる四人のパソコン科学者です。私のけ願書で勉強したことではなく、翻訳書や解説書で勉強したのでgofに関して詳しく説明ができません。とにかく、その四人がプログラムコードを作成する方法でどうすれば効率的なコードパターンを設計できるか、実際の業務からプログラムに作成する時に綺麗に解析できるパターンを纏めておいたことです。でも、今はこのデザインパターンは効率的な設計パターンとしても重要ですが、開発者(デベロッパー)の間の暗黙的なコードルールもあります。例として私の経験を話します。私が大学校を通う時、つまり役10年前にはデザインパターンを軽く勉強したことがあります。その時にはオブジェクト指向プログラミング(oop)を完全に理解できない状況で勉強しようと思ったので理解もよくできませんでした。また、先輩からもデザインパターンはプログラムを勉強することで邪魔だと聞いたことがあるので重要だと思っていませんでした。その状況で卒業して実務経験で3~4年の時に実力が停滞期が来ました。その時に設計実力も伸びないし勉強しても、毎回の基礎研究に大変でした。それで始まったことはopen source projectに参加することでした。オープンソースプロジェクトに参加してショックをたくさん貰いました。その時にプログラム開発に関して自身もあったし勉強も十分だと思いましたが、オープンソースが全然理解できませんでした。同然、理解ができないから参加も上手くできないし、時々に理解できる部分があって修正して要請(request)してもいつも断り(decline)でした。個人的にすごくスランプが来た時でした。その状況でいつも断り(decline)だけ貰って、勇気を出してなぜ断り(decline)ですかと聞きました。返事はコーディング規約も合わないし、パターン式で解決しなければならないので、単純コーディングアルゴリズムで解決しようとするから他のバグが発生する可能があると答えを貰いました。今、考えてもすごくショックですが、その後からプログラムプロジェクト工程や設計テクニック、標準規約などがなぜ

Study / Design pattern

Design pattern

作成日付 : 2021/06/08 20:42:36       修正日付 : 2021/06/08 20:42:36