まえがき
こんにちは、Habrの親愛なるユーザー。 この出版物は、 Singletonを使用するための規則ではなく、このパターンの私のビジョンに焦点を当てます。
私は完全に緑だと警告したい。 私はプログラミングの第一人者でも、上級者でも、中級者でもありません。 私はUnityだけで十分な開発経験を持っているため、この環境にのみ影響を与えます。 当初、私の考えを共有するのは怖かったのですが、時々
シングルトンパターンが嫌いな理由
その理由は信じられないほどたくさんありますが、SOLIDコードの勇敢な擁護者として自分自身を見せようとして、それらの多くは絶対に空から取られていることが明らかになりました。
それらのいくつかを見てみましょう！
唯一の責任の原則に対する違反。 すみません、何？ 100％の確率でLonerがこの原則に違反するのはどのような理由ですか？ クラスにグローバルアクセスポイントがあるという事実は、それをGODクラスのカテゴリに転送しません。 SoundManager？ NetworkManager？ SceneManager？ Unity3Dの公式チュートリアルでも、SoundManagerはシングルトンによって作成されました。 どうやら、このアイテムは消えます。
シングルトンをテストすることは不可能です。 言い換えれば、人々の議論は、Lonerはオブジェクトと強く結びついており、最初はメモリに保存されており、アプリケーションから除外してテストを実行することは不可能だということです。 おそらく、MonoBehaviourクラスのライフサイクルを理解していない人にとっては、そうでしょう。 しかし、清潔さについて話しましょう。 唯一のインスタンスがAwake（）メソッドで作成されるという事実は、これがシングルトンを作成するための前提条件であることを意味するものではありません。 他のメソッドで初期化をラップし、最初に必要なときにのみ作成できます。 さらに、何らかの理由で、シングルトンはシーンを通じて
接続を閉じます 。 何千行ものひどく関連するコードを書いたので、他のクラスを変更するときに、あるクラスに現れるバグに苦しむことは誰にも理解できない。 しかし、シングルトンがこの問題の原因だと思いますか？ しません。 デザイン、そして再びデザイン。 記事の1つ（すみません、信じられないほど長く読んだためリンクを提供できません）は、アプリケーションの構造を設計するために最大80％の時間を費やす必要があり、その後物事は時計仕掛けのようになると述べました。 私はそれに完全に同意します。
実際、 モジュール性については熱狂的です 。 各モジュールが自給自足で拡張可能かつシンプルになるような構造を考えて作成すること-私の夢は、現時点でのプログラミングの観点です。
今日、私はScriptable Objectsの使用に関する信じられないほど有益なプレゼンテーションを見ました。 Unite Austin 2017-Scriptable Objectを使用したGame Architectureと呼ばれます。 この資料は、すべてのUnity開発者にとって有用です。 スピーカーはシングルトンを自然災害、核戦争と同一視し、彼らのスタジオは自給自足で密接な関係のないゲームのプレハブを作成しようとしていると述べました。 私の意見では、繰り返しますが、解決策は優れています。 しかし、ゲームに接続が必要な場合はどうでしょうか？
Scriptable Objectsを使用する主な例の1つは、ご存知かもしれませんが、Unity3Dで部分的に作成されたゲームHeart Stoneです。 かっこいい。 素晴らしい。 すごい。 1つの大きな「BUT」だけがわずらわしい。 Heart Stoneのカードの作成は、Excelのプレートに限定できます。ここでは、カードの名前、説明、マナ、攻撃、そしてもちろん、ヒットポイントを打ち込みます。 できた そして、すべてが世代に結び付けられたゲームを作成する必要がありました。 ランドスケープが生成され、オブジェクトが生成され、キャラクターが生成されます。生成に関与するものも生成されます。 工場の一つのパターン？ ビルダー？ まあ多分。 私たちの先生は嘘をつきそうにありません。 これらのパターンの欠点は、余分なコードとその一般的な複雑さでオーバーロードされます。 決して、Singleton以外のパターンの使用を放棄する必要があるとは言いません。Lonerを恐れず、必要のないパターンを生成しないように人々に奨励したいだけです。これは、アーキテクチャの不適切な複雑化につながる可能性があります。
いくつかの追加
多くの場合、「シングルトンではない」ように見えるソリューションを見ることができます。 開発者は、あらゆる手段によって歪曲されています。 これらは、このリンクを必要とする数百の他のオブジェクトに目的のクラスを持つ唯一のオブジェクトをインスペクターにドラッグアンドドロップすることで、クラスのパブリック変数を作成します。 GameObject.Find（）のStart（）メソッドで呼び出されます。 しかし、シングルトンではない、素晴らしいですね？ つながりがあり、アンチパターンはありません。 奇跡
初心者開発者の間のシングルトンの主な問題は、構造についてよく考える必要がないことです。 そのため、すべてのコードはLonersで大きくなりすぎています。 リンクのない任意の方法、モノリシックアーキテクチャへのアクセス。 これはすべて悪いことですが、誰もがコードを読み書き能力の及ぶ限りで記述します。 正直になります。 プログラミングは単なる活動の一種ではなく、考え方の完全な変化です。 700ページの本を読んだり、座って完璧な建築を作ることは不可能です。 すべてには経験が必要です。 そして、もしあなたの旅がモノリスから始まったなら、これは全く絶望する理由ではありません。 問題を理解することが、問題を解決する最初のステップです！
また 、シングルトンの使いすぎは、他のパターンの使いすぎとまったく同じです。 背景画像を変更することだけを目的とするクラスの抽象ファクトリーと30のインターフェースを作成するためのCookieを誰も提供しません。
7回測定し、1回切ります！
おそらく、コメントが非常に豊富な場合は、この記事を補足するか、パート2を行うこともできます。 私の著作に対する批判を期待します。 ご清聴ありがとうございました！