このメモでは、さまざまな (成功したプロジェクトとそれほど成功していない) プロジェクトに取り組みながら、シングルトン パターン (外国文学におけるシングルトン) を使用したときの私の経験と同僚の経験について説明します。このパターンがどこにも使用できないと私が個人的に考える理由を説明し、チーム内のどのような心理的要因がこのアンチパターンの統合に影響を与えるかについても説明します。チームメンバーの一人が扱いやすく、特別な世話や世話の知識を必要としない小さなかわいい子犬を連れてきたことからすべてが始まり、飼育された野獣で終わった理由を理解しようとしていた倒れた、不自由な開発者全員に捧げます。あなたのプロジェクトを人質に取り、ますます多くの工数を必要とし、ユーザーの神経とお金を食いつぶし、一見単純な実装を評価するためにまったく途方もない数字を生み出すことになります。
Wolf in sheep’s clothing by SarahRichterArt
物語は別の宇宙で起こり、すべての偶然はランダムです…
Cat@Home を使用して自宅で猫を撫でましょう
誰でも、人生の中で猫を撫でたいという抑えがたい欲求を抱くことがあります。世界中のアナリストは、猫の配達とレンタルのアプリケーションを作成した最初のスタートアップが非常に人気となり、 近い将来モーグリに数兆ドルで買収されるだろうと予測しています。すぐにこれが起こります–チュメニ出身の男がCat@Home アプリケーションを作成し、すぐに億万長者になり、モーグリ 会社は新たな利益源を獲得し、何百万ものストレスを抱えた人々が次の機会を得ることができました。猫に家に来てもらい、さらにアイロンをかけ、落ち着かせてもらいます。
クローンの攻撃
ムルマンスク出身の非常に裕福な歯科医、アレクセイ ゴロボロドコは、フォーブス誌の Cat@Home に関する記事に感銘を受け、自分も天文学的なお金持ちになりたいと決意しました。この目標を達成するために、彼は友人を通じて Goldfield – の会社を見つけました。ソフトウェア開発サービスを提供する Wakeboard DevPops は、Cat@Home クローンの開発を同社に発注します。
優勝チーム
このプロジェクトは Fur&Pure と呼ばれ、20 人の有能な開発チームに委託されています。次に、5 人からなるモバイル開発チームに注目してみましょう。各チームメンバーはアジャイルとスクラムを武器に自分の仕事に従事し、チームは予定通り (6 か月以内) バグもなく開発を完了し、iStore でアプリケーションをリリースし、100,000 人のユーザーから 5 と評価されます。アプリケーションの素晴らしさ、サービスの素晴らしさ (結局のところ、代替世界) に関するコメント。猫にはアイロンがけが施され、アプリはリリースされ、すべてが順調に進んでいるように見えます。ただし、Cat@Home には猫だけでなく犬もすでに登場しているため、モーグリはスタートアップを数兆ドルで買収することを急いでいません。
犬が吠え、キャラバンは進む
アプリケーションの所有者は、アプリケーションに犬を追加する時期が来たと判断し、会社に評価を依頼し、 アプリケーションに犬を追加するために少なくとも 6 か月の猶予を受け取ります。実際には、アプリケーションは再び最初から作成されます。この期間中、Moogle はヘビ、クモ、モルモットをアプリケーションに追加し、Fur&Pur は犬のみを受け取ります。
なぜこのようなことが起こったのでしょうか?柔軟なアプリケーション アーキテクチャの欠如がすべての原因です。最も一般的な要因の 1 つはシングルトンのアンチパターンです。
何が問題ですか?
自宅で猫を注文するには、消費者はリクエストを作成してオフィスに送信する必要があります。オフィスはそれを処理し、猫を連れた宅配便を送ります。宅配便はすでにサービスの代金を受け取っています。
プログラマーの 1 人がクラス「Cat Application」を作成することにしました。必要なフィールドを指定すると、 このクラスがシングルトンを通じてグローバル アプリケーション空間に組み込まれます。なぜ彼はこんなことをしているのでしょうか？時間を節約するため (30 分の 1 ペニーの節約)。アプリケーションのアーキテクチャを熟考して依存関係の注入を使用するよりも、アプリケーションを公開する方が簡単だからです。次に、他の開発者がこのグローバル オブジェクトを選択し、クラスをそれにバインドします。 たとえば、すべての画面自体がグローバル オブジェクト「Cat Request」にアクセスします。アプリケーション上のデータを表示します。その結果、このようなモノリシックなアプリケーションがテストされ、リリースされる
ことになります。すべてがうまくいっているように見えますが、突然、アプリケーションに犬のリクエストを追加するという要件を要求する顧客が表示されます。チームは、システム内のいくつのコンポーネントがこの変更によって影響を受けるかを必死で評価し始めます。分析の最後に、アプリケーションに「猫のリクエスト」だけでなくリクエストも受け入れるように教えるには、コードの 60 ～ 90% をやり直す必要があることが判明しました。しかし、「犬の申請」も同様です。少なくとも 2 頭の動物に対処するには、この段階で他の動物の追加を評価することはすでに無意味です。
シングルトンを防ぐ方法
まず、要件収集の段階で、柔軟で拡張可能なアーキテクチャを作成する必要性を明示します。第二に、弱点の調査を義務付けて、製品コードの独立したレビューを並行して実施する価値があります。あなたが開発者で、シングルトンが大好きな場合は、手遅れになる前に正気に戻ることをお勧めします。そうしないと、眠れない夜と神経のすり減りが確実です。多数のシングルトンを含むレガシー プロジェクトに取り組んでいる場合は、できるだけ早くシングルトンまたはプロジェクトを削除するようにしてください。
シングルトン – グローバル オブジェクト/ 変数のアンチパターンから依存関係の注入に切り替える必要があります。必要なすべてのデータが初期化段階でクラスのインスタンスに与えられる最も単純な設計パターンであり、グローバル空間にさらにバインドする必要はありません。
ソース
https://stackoverflow. com/questions/137975/what-is-so-bad-about-singletons
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
https://blog.ndepend.com/singleton-pattern-costs/