Có bất kỳ lựa chọn thay thế khả thi nào cho Mô hình GOF Singleton không?

Hãy đối mặt với nó. Mô hình Singleton là chủ đề gây tranh cãi lớn với đám đông lập trình viên ở cả hai bên hàng rào. Có những người cảm thấy Singleton không hơn gì một biến toàn cầu được tôn vinh, và những người khác thì thề theo khuôn mẫu và sử dụng nó không ngừng. Tuy nhiên, tôi không muốn Cuộc tranh cãi Singleton nằm ở trọng tâm của câu hỏi của tôi. Mọi người đều có thể kéo co và chiến đấu và xem ai thắng cho tất cả những gì tôi quan tâm . Điều tôi muốn nói là, tôi không tin có một câu trả lời chính xác và tôi không cố ý thổi phồng những cuộc cãi vã của đảng phái. Tôi chỉ quan tâm đến các lựa chọn thay thế singleton khi tôi đặt câu hỏi:

Có bất kỳ lựa chọn thay thế cụ thể nào cho Mô hình GOF Singleton không?

Ví dụ, nhiều lần khi tôi đã sử dụng mô hình singleton trong quá khứ, tôi chỉ đơn giản quan tâm đến việc bảo toàn trạng thái / giá trị của một hoặc một số biến. Tuy nhiên, trạng thái / giá trị của các biến có thể được giữ nguyên giữa mỗi lần khởi tạo của lớp bằng cách sử dụng các biến tĩnh thay vì sử dụng mẫu singleton.

Bạn có ý tưởng nào khác?

CHỈNH SỬA: Tôi không thực sự muốn đây là một bài đăng khác về "cách sử dụng singleton một cách chính xác." Một lần nữa, tôi đang tìm cách để tránh nó. Để giải trí, ok? Tôi đoán tôi đang hỏi một câu hoàn toàn mang tính học thuật bằng giọng nói trong đoạn giới thiệu phim hay nhất của bạn, "Trong một vũ trụ song song không có singleton, chúng ta có thể làm gì?"

Alex Miller trong " Những mẫu tôi ghét " đã trích dẫn những điều sau:

"Khi một singleton dường như là câu trả lời, tôi thấy nó thường khôn ngoan hơn nếu:

1. Tạo giao diện và triển khai mặc định cho singleton của bạn
2. Xây dựng một phiên bản triển khai mặc định của bạn ở “đầu” hệ thống của bạn. Điều này có thể nằm trong cấu hình Spring, hoặc trong mã, hoặc được định nghĩa theo nhiều cách khác nhau tùy thuộc vào hệ thống của bạn.
3. Truyền cá thể đơn lẻ vào từng thành phần cần nó (chèn phụ thuộc)

Để hiểu cách thích hợp để giải quyết các Singletons, bạn cần hiểu những gì sai với Singletons (và trạng thái toàn cầu nói chung):

Singleton ẩn các phụ thuộc.

Tại sao điều đó lại quan trọng?

Bởi vì Nếu bạn ẩn các phụ thuộc, bạn có xu hướng mất dấu số lượng khớp nối.

Bạn có thể tranh luận rằng

void purchaseLaptop(String creditCardNumber, int price){
  CreditCardProcessor.getInstance().debit(creditCardNumber, amount);
  Cart.getInstance().addLaptop();
}

đơn giản hơn

void purchaseLaptop(CreditCardProcessor creditCardProcessor, Cart cart, 
                    String creditCardNumber, int price){
  creditCardProcessor.debit(creditCardNumber, amount);
  cart.addLaptop();
}

nhưng ít nhất API thứ hai cũng làm cho nó rõ ràng chính xác những người cộng tác của phương pháp là gì.

Vì vậy, cách giải quyết các Singletons không phải là sử dụng các biến tĩnh hoặc bộ định vị dịch vụ, mà là thay đổi các lớp Singleton thành các thể hiện, được khởi tạo trong phạm vi mà chúng có ý nghĩa và được đưa vào các thành phần và phương thức cần chúng. Bạn có thể sử dụng IoC-framework để xử lý điều này hoặc bạn có thể làm điều đó theo cách thủ công, nhưng điều quan trọng là loại bỏ trạng thái toàn cục của bạn và làm cho các phụ thuộc và cộng tác rõ ràng.

Giải pháp tốt nhất mà tôi đã thử là sử dụng factory pattern để xây dựng các thể hiện của các lớp của bạn. Sử dụng mô hình, bạn có thể đảm bảo rằng chỉ có một thể hiện của một lớp được chia sẻ giữa các đối tượng sử dụng nó.

Tôi mặc dù nó sẽ phức tạp để quản lý, nhưng sau khi đọc bài đăng trên blog này "Tất cả các Singletons đã đi đâu?", nó có vẻ rất tự nhiên. Và ngoài ra, nó giúp ích rất nhiều cho việc cô lập các bài kiểm tra đơn vị của bạn.

Tóm lại, bạn cần phải làm gì? Bất cứ khi nào một đối tượng phụ thuộc vào đối tượng khác, nó sẽ chỉ nhận một thể hiện của nó thông qua hàm tạo của nó (không có từ khóa mới trong lớp của bạn).

class NeedyClass {

    private ExSingletonClass exSingleton;

    public NeedyClass(ExSingletonClass exSingleton){
        this.exSingleton = exSingleton;
    }

    // Here goes some code that uses the exSingleton object
}

Và sau đó, nhà máy.

class FactoryOfNeedy {

    private ExSingletonClass exSingleton;

    public FactoryOfNeedy() {
        this.exSingleton = new ExSingletonClass();
    }

    public NeedyClass buildNeedy() {
        return new NeedyClass(this.exSingleton);
    }
}

Vì bạn chỉ khởi tạo nhà máy của mình một lần, nên sẽ có một lần khởi tạo exSingleton. Mỗi khi bạn gọi buildNeedy, phiên bản mới của NeedyClass sẽ được đóng gói với exSingleton.

Tôi hi vọng cái này giúp được. Xin vui lòng chỉ ra bất kỳ sai lầm.

Spring hoặc bất kỳ IoC-Container nào khác làm rất tốt việc đó. Vì các lớp được tạo và quản lý bên ngoài chính ứng dụng, nên vùng chứa có thể tạo các lớp đơn giản và chèn chúng khi cần thiết.

Bạn không cần phải ra ngoài để tránh bất kỳ khuôn mẫu nào. Việc sử dụng một mẫu hoặc là một quyết định thiết kế hoặc một sự phù hợp tự nhiên (nó chỉ rơi vào đúng vị trí). Khi bạn thiết kế một hệ thống, bạn có thể lựa chọn sử dụng một mẫu hoặc không sử dụng mẫu. Tuy nhiên, bạn không nên tránh né bất cứ thứ gì mà cuối cùng vẫn là lựa chọn thiết kế.

Tôi không tránh Mô hình Singleton. Hoặc nó phù hợp và tôi sử dụng nó hoặc nó không phù hợp và tôi không sử dụng nó. Tôi tin rằng nó chỉ đơn giản như vậy.

Sự phù hợp (hoặc thiếu) của Singleton phụ thuộc vào tình huống. Đó là một quyết định thiết kế phải được thực hiện và hậu quả của quyết định đó phải được hiểu (và được lập thành văn bản).

Monostate (được mô tả trong Phát triển phần mềm Agile của Robert C. Martin) là một giải pháp thay thế cho singleton. Trong mẫu này, dữ liệu của lớp đều là tĩnh nhưng getters / setters là không tĩnh.

Ví dụ:

public class MonoStateExample
{
    private static int x;

    public int getX()
    {
        return x;
    }

    public void setX(int xVal)
    {
        x = xVal;
    }
}

public class MonoDriver
{
    public static void main(String args[])
    {
        MonoStateExample m1 = new MonoStateExample();
        m1.setX(10);

        MonoStateExample m2 = new MonoStateExample();
        if(m1.getX() == m2.getX())
        {
            //singleton behavior
        }
    }
}

Monostate có hành vi tương tự như singleton nhưng làm như vậy theo cách mà lập trình viên không nhất thiết phải biết thực tế là một singleton đang được sử dụng.

Các singleton pattern tồn tại vì có những tình huống khi một đối tượng duy nhất là cần thiết để cung cấp một tập hợp các dịch vụ .

Ngay cả khi trường hợp này xảy ra, tôi vẫn xem xét cách tiếp cận tạo các thẻ đơn bằng cách sử dụng trường / thuộc tính tĩnh toàn cục đại diện cho phiên bản, không phù hợp. Nó không phù hợp vì nó tạo ra sự phụ thuộc trong mã giữa trường tĩnh và đối tượng không phải là các dịch vụ mà đối tượng cung cấp.

Vì vậy, thay vì mẫu singleton cổ điển, tôi khuyên bạn nên sử dụng mẫu 'like' dịch vụ với các vùng chứa được phục vụ , trong đó thay vì sử dụng singleton của bạn thông qua trường tĩnh, bạn có được tham chiếu đến nó thông qua phương thức aa yêu cầu loại dịch vụ được yêu cầu.

*pseudocode* currentContainer.GetServiceByObjectType(singletonType)
//Under the covers the object might be a singleton, but this is hidden to the consumer.

thay vì toàn cầu duy nhất

*pseudocode* singletonType.Instance

Bằng cách này khi bạn muốn thay đổi kiểu của một đối tượng từ singleton sang một thứ khác, bạn sẽ có và dễ dàng thực hiện nó. Cũng như một lợi ích bổ sung, bạn không cần phải chuyển toàn bộ các phiên bản đối tượng cho mọi phương thức.

Ngoài ra, hãy xem Inversion of Control , ý tưởng là bằng cách hiển thị các đơn lẻ trực tiếp cho người tiêu dùng, bạn tạo ra sự phụ thuộc giữa người tiêu dùng và cá thể đối tượng, chứ không phải các dịch vụ đối tượng được cung cấp bởi đối tượng.

Ý kiến ​​của tôi là ẩn việc sử dụng mô hình singleton bất cứ khi nào có thể, bởi vì không phải lúc nào cũng có thể tránh được hoặc mong muốn.

Nếu bạn đang sử dụng Singleton để đại diện cho một đối tượng dữ liệu, bạn có thể chuyển một đối tượng dữ liệu xung quanh dưới dạng một tham số phương thức.

(mặc dù, tôi cho rằng đây là cách sử dụng Singleton sai lầm ngay từ đầu)

Nếu vấn đề của bạn là bạn muốn giữ trạng thái, bạn muốn có một lớp MumbleManager. Trước khi bạn bắt đầu làm việc với một hệ thống, khách hàng của bạn tạo một MumbleManager, trong đó Mumble là tên của hệ thống. Trạng thái được giữ lại thông qua đó. Rất có thể MumbleManager của bạn sẽ chứa một túi tài sản chứa trạng thái của bạn.

Kiểu này có cảm giác rất giống C và không giống đối tượng lắm - bạn sẽ thấy rằng các đối tượng xác định hệ thống của bạn đều sẽ có tham chiếu đến cùng một MumbleManager.

Sử dụng một đối tượng thuần túy và một đối tượng gốc. Nhà máy chịu trách nhiệm lập chính sách cho cá thể và chi tiết đối tượng thuần túy chỉ với thông tin cấu hình (ví dụ: nó chứa) và hành vi.

Trên thực tế, nếu bạn thiết kế ngay từ đầu để tránh các Singeltons, bạn có thể không phải làm việc xung quanh việc không sử dụng Singletons bằng cách sử dụng các biến tĩnh. Khi sử dụng các biến tĩnh, ít nhiều bạn cũng đang tạo một Singleton, sự khác biệt duy nhất là bạn đang tạo các thể hiện đối tượng khác nhau, tuy nhiên bên trong chúng đều hoạt động như thể chúng đang sử dụng Singleton.

Bạn có thể đưa ra một ví dụ chi tiết về nơi bạn sử dụng Singleton hoặc nơi Singleton hiện đang được sử dụng và bạn đang cố gắng tránh sử dụng nó? Điều này có thể giúp mọi người tìm ra một giải pháp lạ mắt hơn để xử lý tình huống mà không có Singleton nào cả.

BTW, cá nhân tôi không có vấn đề gì với Singletons và tôi không thể hiểu những vấn đề mà người khác gặp phải về Singletons. Tôi thấy không có gì xấu về họ. Đó là, nếu bạn không lạm dụng chúng. Mọi kỹ thuật hữu ích đều có thể bị lạm dụng và nếu bị lạm dụng, nó sẽ dẫn đến kết quả tiêu cực. Một kỹ thuật khác thường được sử dụng sai là kế thừa. Vẫn không ai có thể nói thừa kế là điều gì đó xấu chỉ vì một số người lạm dụng nó một cách khủng khiếp.

Theo cá nhân tôi, cách hợp lý hơn nhiều để triển khai một thứ gì đó hoạt động như singleton là sử dụng lớp tĩnh hoàn toàn (thành viên tĩnh, phương thức tĩnh, thuộc tính tĩnh). Hầu hết thời gian tôi triển khai nó theo cách này (tôi không thể nghĩ ra bất kỳ sự khác biệt nào về hành vi theo quan điểm của người dùng)

Tôi nghĩ nơi tốt nhất để cảnh sát singleton là ở cấp độ thiết kế đẳng cấp. Ở giai đoạn này, bạn sẽ có thể vạch ra sự tương tác giữa các lớp và xem liệu có điều gì đó hoàn toàn, chắc chắn yêu cầu rằng chỉ có 1 thể hiện của lớp này tồn tại tại bất kỳ thời điểm nào của vòng đời ứng dụng hay không.

Nếu đúng như vậy, thì bạn có một singleton. Nếu bạn đang sử dụng các singleton như một sự tiện lợi trong quá trình viết mã thì bạn thực sự nên xem xét lại thiết kế của mình và cũng ngừng viết mã các singleton đã nói :)

Và vâng, 'cảnh sát' là từ tôi muốn nói ở đây hơn là 'tránh'. Singleton không phải là thứ nên tránh (giống như cách mà goto và các biến toàn cục không phải là thứ nên tránh). Thay vào đó, bạn nên giám sát việc sử dụng nó và đảm bảo rằng nó là phương pháp tốt nhất để hoàn thành những gì bạn muốn một cách hiệu quả.

Tôi sử dụng singleton chủ yếu là "vùng chứa phương thức", không có trạng thái nào cả. Nếu tôi cần chia sẻ các phương thức này với nhiều lớp và muốn tránh gánh nặng của việc khởi tạo và khởi tạo, tôi tạo một ngữ cảnh / phiên và khởi tạo tất cả các lớp ở đó; mọi thứ đề cập đến phiên cũng có quyền truy cập vào "singleton" do đó chứa.

Không được lập trình trong một môi trường hướng đối tượng mạnh mẽ (ví dụ như Java), tôi không hoàn toàn hiểu về sự phức tạp của cuộc thảo luận. Nhưng tôi đã triển khai một singleton trong PHP 4. Tôi đã làm điều đó như một cách để tạo một trình xử lý cơ sở dữ liệu 'hộp đen' tự động khởi tạo và không phải chuyển lên xuống các lệnh gọi hàm trong một khuôn khổ không hoàn chỉnh và có phần bị hỏng.

Sau khi đọc một số liên kết của các mẫu singleton, tôi không hoàn toàn chắc chắn rằng mình sẽ triển khai lại nó theo cách tương tự. Những gì thực sự cần thiết là nhiều đối tượng với bộ nhớ được chia sẻ (ví dụ: bộ xử lý cơ sở dữ liệu thực tế) và đây là những gì mà cuộc gọi của tôi đã biến thành.

Giống như hầu hết các mẫu và thuật toán, sử dụng một nút duy nhất 'chỉ vì nó thú vị' là Điều sai lầm cần làm. Tôi cần một lệnh gọi 'hộp đen' thực sự trông giống như một singleton. Và IMO đó là cách để giải quyết câu hỏi: nhận thức về mô hình, nhưng cũng xem xét phạm vi rộng hơn của nó và ở cấp độ nào thì thể hiện của nó cần phải là duy nhất.

Ý bạn là gì, kỹ thuật của tôi để tránh nó là gì?

Để "tránh" nó, điều đó ngụ ý rằng có rất nhiều tình huống mà tôi gặp phải trong đó mô hình singleton phù hợp một cách tự nhiên, và do đó tôi phải thực hiện một số biện pháp để giải quyết những tình huống này.

Nhưng không có. Tôi không cần phải tránh mô hình singleton. Nó chỉ đơn giản là không phát sinh.