Singleton: Nên sử dụng như thế nào

Chỉnh sửa: Từ một câu hỏi khác, tôi đã cung cấp một câu trả lời có liên kết đến rất nhiều câu hỏi / câu trả lời về singletons: Thông tin thêm về singletons tại đây:

Vì vậy, tôi đã đọc chủ đề Singletons: thiết kế tốt hay một cái nạng?
Và cuộc cãi vã vẫn còn hoành hành.

Tôi thấy Singletons là một mẫu thiết kế (tốt và xấu).

Vấn đề với Singleton không phải là Mẫu mà là người dùng (xin lỗi mọi người). Mọi người và cha của họ nghĩ rằng họ có thể thực hiện một cách chính xác (và từ nhiều cuộc phỏng vấn tôi đã thực hiện, hầu hết mọi người không thể). Ngoài ra bởi vì mọi người nghĩ rằng họ có thể triển khai một Singleton chính xác, họ lạm dụng Mẫu và sử dụng nó trong các tình huống không phù hợp (thay thế các biến toàn cục bằng Singletons!).

Vì vậy, những câu hỏi chính cần được trả lời là:

• Khi nào bạn nên sử dụng Singleton
• Làm thế nào để bạn thực hiện một Singleton chính xác

Hy vọng của tôi cho bài viết này là chúng ta có thể thu thập cùng nhau ở một nơi (thay vì phải tìm kiếm trên google và tìm kiếm nhiều trang web) một nguồn có thẩm quyền khi nào (và sau đó làm thế nào) để sử dụng Singleton một cách chính xác. Cũng thích hợp sẽ là một danh sách các Chống sử dụng và các triển khai xấu phổ biến giải thích lý do tại sao chúng không hoạt động và để thực hiện tốt các điểm yếu của chúng.

Vì vậy, có được quả bóng lăn:
Tôi sẽ giơ tay lên và nói đây là những gì tôi sử dụng nhưng có lẽ có vấn đề.
Tôi thích cách xử lý "Scott Myers" của chủ đề trong cuốn sách "Hiệu quả C ++"

Các tình huống tốt để sử dụng Singletons (không nhiều):

• Ghi nhật ký khung
• Bể tái chế

/*
 * C++ Singleton
 * Limitation: Single Threaded Design
 * See: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf
 *      For problems associated with locking in multi threaded applications
 *
 * Limitation:
 * If you use this Singleton (A) within a destructor of another Singleton (B)
 * This Singleton (A) must be fully constructed before the constructor of (B)
 * is called.
 */
class MySingleton
{
    private:
        // Private Constructor
        MySingleton();
        // Stop the compiler generating methods of copy the object
        MySingleton(MySingleton const& copy);            // Not Implemented
        MySingleton& operator=(MySingleton const& copy); // Not Implemented

    public:
        static MySingleton& getInstance()
        {
            // The only instance
            // Guaranteed to be lazy initialized
            // Guaranteed that it will be destroyed correctly
            static MySingleton instance;
            return instance;
        }
};

ĐỒNG Ý. Cho phép nhận được một số lời chỉ trích và thực hiện khác cùng nhau.
:-)

Tất cả các bạn đều sai. Đọc câu hỏi. Câu trả lời:

Sử dụng Singleton nếu:

• Bạn cần phải có một và chỉ một đối tượng của một loại trong hệ thống

Không sử dụng Singleton nếu:

• Bạn muốn tiết kiệm bộ nhớ
• Bạn muốn thử một cái gì đó mới
• Bạn muốn thể hiện bao nhiêu bạn biết
• Bởi vì mọi người khác đang làm điều đó (Xem lập trình viên sùng bái hàng hóa trong wikipedia)
• Trong các widget giao diện người dùng
• Nó được coi là một bộ đệm
• Trong chuỗi
• Trong phiên
• Tôi có thể đi cả ngày

Làm thế nào để tạo ra singleton tốt nhất:

• Càng nhỏ, càng tốt. Tôi là người tối giản
• Hãy chắc chắn rằng nó là chủ đề an toàn
• Hãy chắc chắn rằng nó không bao giờ là null
• Hãy chắc chắn rằng nó chỉ được tạo một lần
• Lười hay khởi tạo hệ thống? Theo yêu cầu của bạn
• Đôi khi, HĐH hoặc JVM tạo ra các singletons cho bạn (ví dụ: trong Java, mỗi định nghĩa lớp là một singleton)
• Cung cấp một hàm hủy hoặc bằng cách nào đó tìm ra cách loại bỏ tài nguyên
• Sử dụng ít bộ nhớ

Singletons cung cấp cho bạn khả năng kết hợp hai đặc điểm xấu trong một lớp. Điều đó sai ở mọi khía cạnh.

Một đơn cho bạn:

1. Toàn cầu truy cập vào một đối tượng và
2. Đảm bảo rằng không có nhiều hơn một đối tượng thuộc loại này có thể được tạo

Số một là đơn giản. Globals nói chung là xấu. Chúng ta không bao giờ nên làm cho các đối tượng có thể truy cập trên toàn cầu trừ khi chúng ta thực sự cần nó.

Số hai nghe có vẻ hợp lý, nhưng hãy nghĩ về nó. Lần cuối cùng bạn ** vô tình * tạo ra một đối tượng mới thay vì tham chiếu một đối tượng hiện có là khi nào? Vì đây được gắn thẻ C ++, chúng ta hãy sử dụng một ví dụ từ ngôn ngữ đó. Bạn có thường xuyên vô tình viết

std::ostream os;
os << "hello world\n";

Khi bạn định viết

std::cout << "hello world\n";

Dĩ nhiên là không. Chúng tôi không cần bảo vệ chống lại lỗi này, vì loại lỗi đó không xảy ra. Nếu vậy, phản ứng chính xác là về nhà và ngủ trong 12-20 giờ và hy vọng bạn cảm thấy tốt hơn.

Nếu chỉ cần một đối tượng, chỉ cần tạo một thể hiện. Nếu một đối tượng nên có thể truy cập toàn cầu, hãy biến nó thành toàn cầu. Nhưng điều đó không có nghĩa là không thể tạo ra các phiên bản khác của nó.

Ràng buộc "chỉ có một trường hợp là có thể" không thực sự bảo vệ chúng ta trước các lỗi có thể xảy ra. Nhưng nó không làm cho mã của chúng tôi rất khó để cấu trúc lại và duy trì. Bởi vì khá thường xuyên, chúng tôi tìm hiểu sau đó chúng tôi cần nhiều hơn một ví dụ. Chúng tôi làm có nhiều hơn một cơ sở dữ liệu, chúng tôi làm đã hơn một đối tượng cấu hình, chúng tôi muốn nhiều người khai thác gỗ. Các thử nghiệm đơn vị của chúng tôi có thể muốn có thể tạo và tạo lại các đối tượng này mỗi thử nghiệm, để lấy một ví dụ chung.

Vì vậy, một singleton nên được sử dụng nếu và chỉ nếu, chúng ta cần cả những đặc điểm nó cung cấp: Nếu chúng ta cần phải truy cập toàn cầu (mà là rất hiếm, vì globals thường nản chí) và chúng ta cần để ngăn chặn bất cứ ai từ bao giờ tạo ra nhiều hơn một thể hiện của một lớp (mà âm thanh với tôi như một vấn đề thiết kế). Lý do duy nhất tôi có thể thấy cho điều này là nếu việc tạo hai trường hợp sẽ làm hỏng trạng thái ứng dụng của chúng tôi - có thể là do lớp chứa một số thành viên tĩnh hoặc độ silliness tương tự. Trong trường hợp đó, câu trả lời rõ ràng là sửa lớp đó. Nó không nên phụ thuộc vào việc là ví dụ duy nhất.

Nếu bạn cần quyền truy cập toàn cầu vào một đối tượng, hãy biến nó thành một đối tượng toàn cầu std::cout. Nhưng đừng giới hạn số lượng phiên bản có thể được tạo.

Nếu bạn hoàn toàn, tích cực cần phải hạn chế số lượng phiên bản của một lớp thành một, và không có cách nào tạo ra một thể hiện thứ hai có thể được xử lý một cách an toàn, sau đó thực thi điều đó. Nhưng đừng làm cho nó có thể truy cập trên toàn cầu.

Nếu bạn cần cả hai đặc điểm, thì 1) biến nó thành một cá thể và 2) cho tôi biết bạn cần cái đó để làm gì, bởi vì tôi đang gặp khó khăn khi tưởng tượng một trường hợp như vậy.

Vấn đề với singletons không phải là việc thực hiện của họ. Đó là họ kết hợp hai khái niệm khác nhau, không có khái niệm nào rõ ràng là mong muốn.

1) Singletons cung cấp một cơ chế truy cập toàn cầu đến một đối tượng. Mặc dù chúng có thể là một chủ đề an toàn hơn hoặc đáng tin cậy hơn một chút trong các ngôn ngữ mà không có thứ tự khởi tạo được xác định rõ, cách sử dụng này vẫn tương đương với đạo đức của một biến toàn cục. Đó là một biến toàn cục mặc theo một cú pháp khó xử (foo :: get_instance () thay vì g_foo, giả sử), nhưng nó phục vụ cùng một mục đích chính xác (một đối tượng duy nhất có thể truy cập trên toàn bộ chương trình) và có cùng một nhược điểm.

2) Singletons ngăn chặn nhiều lần xuất hiện của một lớp. Thật hiếm, IME, loại tính năng này nên được đưa vào một lớp. Đó thường là một điều bối cảnh hơn nhiều; rất nhiều thứ được coi là một và chỉ một thực sự chỉ xảy ra một lần duy nhất. IMO một giải pháp phù hợp hơn là chỉ tạo một thể hiện - cho đến khi bạn nhận ra rằng bạn cần nhiều hơn một thể hiện.

Một điều với các mẫu: không khái quát . Họ có tất cả các trường hợp khi chúng hữu ích và khi chúng thất bại.

Singleton có thể khó chịu khi bạn phải kiểm tra mã. Bạn thường bị mắc kẹt với một thể hiện của lớp và có thể chọn giữa việc mở một cánh cửa trong hàm tạo hoặc một phương thức nào đó để đặt lại trạng thái, v.v.

Vấn đề khác là Singleton trong thực tế không có gì khác hơn là một biến toàn cầu được ngụy trang. Khi bạn có quá nhiều trạng thái chia sẻ toàn cầu đối với chương trình của mình, mọi thứ có xu hướng quay trở lại, tất cả chúng ta đều biết điều đó.

Nó có thể làm cho việc theo dõi phụ thuộc khó khăn hơn. Khi mọi thứ phụ thuộc vào Singleton của bạn, việc thay đổi nó thành hai phần khó khăn hơn, v.v. Bạn thường bị mắc kẹt với nó. Điều này cũng cản trở sự linh hoạt. Điều tra một số khuôn khổ tiêm phụ thuộc để cố gắng giảm bớt vấn đề này.

Singletons về cơ bản cho phép bạn có trạng thái toàn cầu phức tạp trong các ngôn ngữ, điều này gây khó khăn hoặc không thể có các biến toàn cầu phức tạp.

Java đặc biệt sử dụng singletons như một sự thay thế cho các biến toàn cục, vì mọi thứ phải được chứa trong một lớp. Các biến gần nhất với các biến toàn cục là các biến tĩnh công khai, có thể được sử dụng như thể chúng là toàn cục vớiimport static

C ++ không có biến toàn cục, nhưng thứ tự xây dựng các biến lớp toàn cầu được gọi là không xác định. Như vậy, một singleton cho phép bạn trì hoãn việc tạo một biến toàn cục cho đến khi lần đầu tiên biến đó là cần thiết.

Các ngôn ngữ như Python và Ruby sử dụng singletons rất ít vì bạn có thể sử dụng các biến toàn cục trong một mô-đun thay thế.

Vậy khi nào thì tốt / xấu khi sử dụng singleton? Chính xác là khi nào thì tốt / xấu khi sử dụng biến toàn cục.

Modern C ++ Design của Alexandrescu có một singleton chung chung an toàn theo chủ đề.

Đối với giá trị 2p của tôi, tôi nghĩ điều quan trọng là phải xác định thời gian sống cho những người độc thân của bạn (khi thực sự cần thiết phải sử dụng chúng). Tôi thường không để get()chức năng tĩnh khởi tạo bất cứ thứ gì, và để lại thiết lập và hủy cho một số phần dành riêng của ứng dụng chính. Điều này giúp làm nổi bật sự phụ thuộc giữa các singletons - nhưng, như đã nhấn mạnh ở trên, tốt nhất là chỉ nên tránh chúng nếu có thể.

• Làm thế nào để bạn thực hiện một Singleton chính xác

Có một vấn đề tôi chưa từng thấy đề cập đến, một điều mà tôi gặp phải ở một công việc trước đây. Chúng tôi có các singletons C ++ được chia sẻ giữa các DLL và các cơ chế thông thường để đảm bảo một thể hiện duy nhất của một lớp không hoạt động. Vấn đề là mỗi DLL có một bộ biến tĩnh riêng, cùng với EXE. Nếu hàm get_instance của bạn là nội tuyến hoặc một phần của thư viện tĩnh, mỗi DLL sẽ kết thúc với bản sao "singleton" của riêng nó.

Giải pháp là đảm bảo mã singleton chỉ được xác định trong một DLL hoặc EXE hoặc tạo một trình quản lý singleton với các thuộc tính đó để phân loại các thể hiện.

Ví dụ đầu tiên không phải là luồng an toàn - nếu hai luồng gọi getInstance cùng một lúc, thì tĩnh đó sẽ là PITA. Một số hình thức của mutex sẽ giúp.

Như những người khác đã lưu ý, những nhược điểm lớn đối với người độc thân bao gồm việc không thể mở rộng chúng và mất khả năng khởi tạo nhiều hơn một trường hợp, ví dụ cho mục đích thử nghiệm.

Một số khía cạnh hữu ích của singletons:

1. lười biếng hoặc trả trước
2. tiện dụng cho một đối tượng yêu cầu thiết lập và / hoặc trạng thái

Tuy nhiên, bạn không phải sử dụng một đơn để có được những lợi ích này. Bạn có thể viết một đối tượng bình thường thực hiện công việc và sau đó cho mọi người truy cập thông qua một nhà máy (một đối tượng riêng biệt). Nhà máy có thể lo lắng về việc chỉ bắt đầu một cái, và tái sử dụng nó, v.v., nếu cần. Ngoài ra, nếu bạn lập trình cho một giao diện chứ không phải là một lớp cụ thể, nhà máy có thể sử dụng các chiến lược, tức là bạn có thể chuyển đổi vào và ra các triển khai khác nhau của giao diện.

Cuối cùng, một nhà máy cho vay các công nghệ tiêm phụ thuộc như Spring, v.v.

Singletons rất tiện lợi khi bạn có nhiều mã được chạy khi bạn khởi tạo và phản đối. Ví dụ, khi bạn sử dụng iBatis khi bạn thiết lập một đối tượng kiên trì, nó phải đọc tất cả các cấu hình, phân tích bản đồ, đảm bảo tất cả đều chính xác, v.v. trước khi nhận mã của bạn.

Nếu bạn làm điều này mỗi lần, hiệu suất sẽ bị suy giảm nhiều. Sử dụng nó trong một singleton, bạn thực hiện cú đánh đó một lần và sau đó tất cả các cuộc gọi tiếp theo không phải thực hiện.

Sự sụp đổ thực sự của Singletons là họ phá vỡ sự kế thừa. Bạn không thể lấy được một lớp mới để cung cấp cho bạn chức năng mở rộng trừ khi bạn có quyền truy cập vào mã nơi Singleton được tham chiếu. Vì vậy, ngoài thực tế, Singleton sẽ làm cho mã của bạn được liên kết chặt chẽ (có thể sửa được bằng Mẫu chiến lược ... hay còn gọi là Dependency Injection), nó cũng sẽ ngăn bạn đóng các phần của mã khỏi sửa đổi (thư viện dùng chung).

Vì vậy, ngay cả các ví dụ về logger hoặc nhóm luồng không hợp lệ và cần được thay thế bởi Strategies.

Hầu hết mọi người sử dụng singletons khi họ đang cố gắng làm cho bản thân cảm thấy tốt khi sử dụng một biến toàn cục. Có những cách sử dụng hợp pháp, nhưng hầu hết thời gian khi mọi người sử dụng chúng, thực tế là chỉ có một trường hợp chỉ là một thực tế tầm thường so với thực tế là nó có thể truy cập toàn cầu.

Bởi vì một singleton chỉ cho phép một cá thể được tạo nên nó kiểm soát sao chép cá thể một cách hiệu quả. ví dụ: bạn không cần nhiều phiên bản tra cứu - ví dụ bản đồ tra cứu morse, do đó gói nó trong một lớp đơn là thích hợp. Và chỉ vì bạn có một thể hiện duy nhất của lớp không có nghĩa là bạn cũng bị giới hạn về số lượng tham chiếu đến thể hiện đó. Bạn có thể xếp hàng các cuộc gọi (để tránh các vấn đề luồng) đến thể hiện và thay đổi hiệu quả cần thiết. Vâng, hình thức chung của một singleton là một công khai toàn cầu, bạn chắc chắn có thể sửa đổi thiết kế để tạo ra một singleton bị hạn chế truy cập hơn. Tôi chưa từng mệt mỏi với điều này trước đây nhưng tôi chắc chắn biết điều đó là có thể. Và với tất cả những người bình luận nói rằng mô hình singleton hoàn toàn xấu xa, bạn nên biết điều này:

Nhưng khi tôi cần một cái gì đó giống như Singleton, tôi thường kết thúc bằng cách sử dụng Bộ đếm Schwarz để khởi tạo nó.

Dưới đây là cách tiếp cận tốt hơn để thực hiện một mẫu singleton an toàn luồng với việc giải phóng bộ nhớ trong chính hàm hủy. Nhưng tôi nghĩ rằng hàm hủy phải là một tùy chọn vì cá thể singleton sẽ tự động bị hủy khi chương trình kết thúc:

#include<iostream>
#include<mutex>

using namespace std;
std::mutex mtx;

class MySingleton{
private:
    static MySingleton * singletonInstance;
    MySingleton();
    ~MySingleton();
public:
    static MySingleton* GetInstance();
    MySingleton(const MySingleton&) = delete;
    const MySingleton& operator=(const MySingleton&) = delete;
    MySingleton(MySingleton&& other) noexcept = delete;
    MySingleton& operator=(MySingleton&& other) noexcept = delete;
};

MySingleton* MySingleton::singletonInstance = nullptr;
MySingleton::MySingleton(){ };
MySingleton::~MySingleton(){
    delete singletonInstance;
};

MySingleton* MySingleton::GetInstance(){
    if (singletonInstance == NULL){
        std::lock_guard<std::mutex> lock(mtx);
        if (singletonInstance == NULL)
            singletonInstance = new MySingleton();
    }
    return singletonInstance;
}

Về các tình huống chúng ta cần sử dụng các lớp singleton có thể- Nếu chúng ta muốn duy trì trạng thái của cá thể trong suốt quá trình thực thi chương trình Nếu chúng ta có liên quan đến việc ghi vào nhật ký thực thi của một ứng dụng trong đó chỉ cần một phiên bản của tệp được sử dụng .... và như vậy. Nó sẽ được đánh giá cao nếu bất cứ ai có thể đề nghị tối ưu hóa trong mã trên của tôi.

Tôi sử dụng Singletons như một bài kiểm tra phỏng vấn.

Khi tôi yêu cầu nhà phát triển đặt tên cho một số mẫu thiết kế, nếu tất cả những gì họ có thể đặt tên là Singleton, họ sẽ không được thuê.

Chống sử dụng:

Một vấn đề lớn với việc sử dụng đơn lẻ quá mức là mô hình ngăn chặn việc mở rộng dễ dàng và hoán đổi các triển khai thay thế. Tên lớp được mã hóa cứng ở bất cứ nơi nào singleton được sử dụng.

Tôi nghĩ rằng đây là phiên bản mạnh mẽ nhất cho C #:

using System;
using System.Collections;
using System.Threading;

namespace DoFactory.GangOfFour.Singleton.RealWorld
{

  // MainApp test application

  class MainApp
  {
    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Same instance?
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 server requests
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // "Singleton"

  class LoadBalancer
  {
    private static LoadBalancer instance;
    private ArrayList servers = new ArrayList();

    private Random random = new Random();

    // Lock synchronization object
    private static object syncLock = new object();

    // Constructor (protected)
    protected LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      // Support multithreaded applications through
      // 'Double checked locking' pattern which (once
      // the instance exists) avoids locking each
      // time the method is invoked
      if (instance == null)
      {
        lock (syncLock)
        {
          if (instance == null)
          {
            instance = new LoadBalancer();
          }
        }
      }

      return instance;
    }

    // Simple, but effective random load balancer

    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

Đây là phiên bản được tối ưu hóa .NET :

using System;
using System.Collections;

namespace DoFactory.GangOfFour.Singleton.NETOptimized
{

  // MainApp test application

  class MainApp
  {

    static void Main()
    {
      LoadBalancer b1 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b2 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b3 = LoadBalancer.GetLoadBalancer();
      LoadBalancer b4 = LoadBalancer.GetLoadBalancer();

      // Confirm these are the same instance
      if (b1 == b2 && b2 == b3 && b3 == b4)
      {
        Console.WriteLine("Same instance\n");
      }

      // All are the same instance -- use b1 arbitrarily
      // Load balance 15 requests for a server
      for (int i = 0; i < 15; i++)
      {
        Console.WriteLine(b1.Server);
      }

      // Wait for user
      Console.Read();    
    }
  }

  // Singleton

  sealed class LoadBalancer
  {
    // Static members are lazily initialized.
    // .NET guarantees thread safety for static initialization
    private static readonly LoadBalancer instance =
      new LoadBalancer();

    private ArrayList servers = new ArrayList();
    private Random random = new Random();

    // Note: constructor is private.
    private LoadBalancer()
    {
      // List of available servers
      servers.Add("ServerI");
      servers.Add("ServerII");
      servers.Add("ServerIII");
      servers.Add("ServerIV");
      servers.Add("ServerV");
    }

    public static LoadBalancer GetLoadBalancer()
    {
      return instance;
    }

    // Simple, but effective load balancer
    public string Server
    {
      get
      {
        int r = random.Next(servers.Count);
        return servers[r].ToString();
      }
    }
  }
}

Bạn có thể tìm thấy mô hình này tại dotfactory.com .

Mẫu đơn Meyers hoạt động đủ tốt hầu hết thời gian, và trong những dịp, nó không nhất thiết phải trả tiền để tìm kiếm bất cứ điều gì tốt hơn. Miễn là người xây dựng sẽ không bao giờ ném và không có sự phụ thuộc giữa các singletons.

Một singleton là một triển khai cho một đối tượng có thể truy cập toàn cầu (GAO kể từ bây giờ) mặc dù không phải tất cả các GAO đều là singletons.

Bản thân logger không nên là singletons nhưng phương tiện để đăng nhập lý tưởng nhất là có thể truy cập được trên toàn cầu, để giải mã nơi thông điệp tường trình được tạo từ nơi hoặc cách đăng nhập.

Đánh giá lười biếng / lười biếng là một khái niệm khác và singleton cũng thường thực hiện điều đó. Nó đi kèm với rất nhiều vấn đề của riêng nó, đặc biệt là vấn đề an toàn và vấn đề nếu nó không thành công với các ngoại lệ sao cho có vẻ như đó là một ý tưởng tốt vào thời điểm đó hóa ra lại không tuyệt vời lắm. (Một chút giống như thực hiện COW trong chuỗi).

Với ý nghĩ đó, GOAs có thể được khởi tạo như thế này:

namespace {

T1 * pt1 = NULL;
T2 * pt2 = NULL;
T3 * pt3 = NULL;
T4 * pt4 = NULL;

}

int main( int argc, char* argv[])
{
   T1 t1(args1);
   T2 t2(args2);
   T3 t3(args3);
   T4 t4(args4);

   pt1 = &t1;
   pt2 = &t2;
   pt3 = &t3;
   pt4 = &t4;

   dostuff();

}

T1& getT1()
{
   return *pt1;
}

T2& getT2()
{
   return *pt2;
}

T3& getT3()
{
  return *pt3;
}

T4& getT4()
{
  return *pt4;
}

Nó không cần phải được thực hiện một cách thô sơ như vậy, và rõ ràng trong một thư viện được tải có chứa các đối tượng mà bạn có thể muốn một số cơ chế khác để quản lý vòng đời của chúng. (Đặt chúng vào một đối tượng mà bạn nhận được khi tải thư viện).

Khi tôi sử dụng singletons? Tôi đã sử dụng chúng cho 2 thứ - Một bảng đơn cho biết những thư viện nào đã được tải với dlopen - Trình xử lý tin nhắn mà logger có thể đăng ký và bạn có thể gửi tin nhắn đến. Cần thiết đặc biệt cho xử lý tín hiệu.

Tôi vẫn không hiểu tại sao một người độc thân phải toàn cầu.

Tôi sẽ tạo ra một singleton nơi tôi ẩn một cơ sở dữ liệu bên trong lớp dưới dạng một biến tĩnh không đổi riêng tư và tạo các hàm lớp sử dụng cơ sở dữ liệu mà không bao giờ để lộ cơ sở dữ liệu cho người dùng.

Tôi không thấy lý do tại sao chức năng này sẽ xấu.

Tôi thấy chúng hữu ích khi tôi có một lớp gói rất nhiều bộ nhớ. Ví dụ, trong một trò chơi gần đây tôi đã làm việc trên tôi có một lớp bản đồ ảnh hưởng có chứa một tập hợp các mảng bộ nhớ liền kề rất lớn. Tôi muốn tất cả được phân bổ khi khởi động, tất cả được giải phóng khi tắt máy và tôi chắc chắn chỉ muốn một bản sao của nó. Tôi cũng phải truy cập nó từ nhiều nơi. Tôi thấy mô hình singleton rất hữu ích trong trường hợp này.

Tôi chắc chắn có những giải pháp khác nhưng tôi thấy giải pháp này rất hữu ích và dễ thực hiện.

Nếu bạn là người đã tạo ra singleton và sử dụng nó, đừng biến nó thành singleton (điều đó không có ý nghĩa vì bạn có thể điều khiển điểm kỳ dị của đối tượng mà không biến nó thành đơn lẻ) nhưng nó có ý nghĩa khi bạn là nhà phát triển của một thư viện và bạn chỉ muốn cung cấp một đối tượng cho người dùng của mình (trong trường hợp này bạn là người đã tạo ra singleton, nhưng bạn không phải là người dùng).

Singletons là đối tượng nên sử dụng chúng làm đối tượng, nhiều người truy cập trực tiếp vào singletons thông qua việc gọi phương thức trả về nó, nhưng điều này có hại vì bạn đang làm cho mã của mình biết rằng đối tượng là singleton, tôi thích sử dụng singletons làm đối tượng, tôi vượt qua chúng thông qua hàm tạo và tôi sử dụng chúng như các đối tượng bình thường, bằng cách đó, mã của bạn không biết liệu các đối tượng này có phải là singletons hay không và điều đó làm cho các phụ thuộc rõ ràng hơn và nó giúp ích một chút cho việc tái cấu trúc ...

Trong các ứng dụng máy tính để bàn (tôi biết, chỉ có chúng ta là khủng long mới viết chúng nữa!) Chúng rất cần thiết để có được các cài đặt ứng dụng toàn cầu tương đối không thay đổi - ngôn ngữ người dùng, đường dẫn để trợ giúp các tệp, tùy chọn người dùng, v.v ... mà phải đi vào mọi lớp và mọi hộp thoại .

Chỉnh sửa - tất nhiên những thứ này chỉ nên đọc!

Thực hiện khác

class Singleton
{
public:
    static Singleton& Instance()
    {
        // lazy initialize
        if (instance_ == NULL) instance_ = new Singleton();

        return *instance_;
    }

private:
    Singleton() {};

    static Singleton *instance_;
};