Flyweightパターンについて

Question

Flyweightパターンを学んでいて疑問に思ったことがあるので質問させてください。
タグにJavaとSwiftをつけたのは私のある程度理解できる言語がその２つだからです。

私が理解するのに読んだ記事はこちらになります。JavaとSwiftで書かれたFlyweightパターンの記事です。
20．Flyweight パターン
Flyweight パターン
Swiftで学ぶデザインパターン20 (Flyweightパターン)

Flyweightパターンに対する質問内容

それぞれの記事でインスタンスを管理するFactoryクラスと対象のクラスが別々に作成されていました。
ここで疑問に思ったことが、対象のクラスはFactoryクラスを通さずにインスタンスの生成が行えてしまうと言うことです。Flyweightで管理する際はあくまでもプログラマが意識して直接インスタンス生成をしないように気をつけなければいけないのでしょうか？

##私なりの考え
上記の問題に関して私が思ったことは、Factoryクラスの中に対象のクラスをprivateで保持しておけばいいのではないかということです。そうすればプログラマが間違って直接対象クラスのインスタンスを生成してしまう事故が無くなるのかなと思いました。
このやり方には何か問題があるのでしょうか？

Answer 1

対象のクラスはFactoryクラスを通さずにインスタンスの生成が行えてしまう

別に生成出来てもいいからではないでしょうか？
生成出来るか出来ないかは、Flyweightパターンとは関係のない話だと思います。

Comments

[hodoru3sei]

私の中のFlyweightパターンのイメージは無駄なインスタンスを作成させないためのパターンです。
個人開発では1つしかないものは普通にインスタンスを生成して重複するものだけFlyweightを使えばいいのかなと思うのですが、チーム開発をする際に、対象のクラスのアクセスを制限しておかないとFlyweightを使わず好き勝手にインスタンスを生成してしまいFlyweight自体が成り立たなくなってしまうんじゃないかなと思いました。

Flyweightは絶対に余計なインスタンスは絶対生成させない！みたいなニュアンスではなく、
重複してしまうインスタンスがある場合Flyweightをつかうこともできるよ！と言う感じなんでしょうか？

Answer 2

ここで疑問に思ったことが、対象のクラスはFactoryクラスを通さずにインスタンスの生成が行えてしまうと言うことです。

完璧に管理したい場合は、「Factoryクラスの中に対象のクラスをprivateで保持」するのもありですし、クラスのネストが煩雑でしたらpackage privateにしてFactoryクラスだけpublicにするなどして、中身のクラスを外から直接触らないようにしておくほうがいいです。

Comments

[hodoru3sei]

私が読んだ記事でそのように記述されていないのは、私のような初心者が理解しやすいように噛み砕いた形になっていたのでしょうか？
それとも実際のプロジェクトでは完璧に管理してしまうことで問題があったりするのでしょうか？

[maisumakun]

管理対象が別に用意されたクラスの場合、封じきる手段は使えません。