Có phải Singletons thực sự tệ đến mức nào?

Question

thể trùng lặp:
What is so bad about Singletons?

Nó hiểu rằng nhiều mẫu thiết kế có thể trong một số trường hợp bị lạm dụng, và giống như mẹ luôn nói rằng: "Quá nhiều của một điều tốt không phải là luôn luôn tốt! "

Tôi nhận thấy rằng những ngày này, tôi đang sử dụng Singletons rất nhiều, và tôi lo lắng rằng tôi có thể tự lạm dụng mẫu thiết kế và chạy dee một và sâu hơn vào một thói quen hành nghề xấu.

Chúng tôi đang phát triển ứng dụng Flex có cấu trúc dữ liệu phân cấp khá lớn được lưu trong bộ nhớ trong khi người dùng làm việc trên đó. Người dùng có thể tải, lưu, thay đổi và làm mới dữ liệu theo yêu cầu.

Dữ liệu này được tập trung bằng phương tiện của một lớp Singleton, tập hợp một vài mảng ArrayCollections, mảng, đối tượng giá trị và một số biến thành viên gốc khác được hiển thị qua getters và setters.

Để có được một tham chiếu đến dữ liệu của chúng tôi từ bất cứ nơi nào trong ứng dụng, chúng tôi làm toàn bộ kiểu phương thức Model.getInstance(), tôi chắc rằng mọi người đều quen thuộc. Điều này đảm bảo rằng chúng tôi luôn luôn có được bàn tay của mình trên cùng một bản sao dữ liệu, kể từ khi chúng tôi thiết kế, chúng tôi đã nói rằng chỉ một lần dụ được phép tồn tại trong suốt thời gian đăng ký.

Từ kho lưu trữ dữ liệu trung tâm này, chúng tôi dễ dàng thay đổi các sự kiện và có thể có nhiều thành phần giao diện người dùng tham chiếu dữ liệu trung tâm, cập nhật màn hình của họ để phản ánh những thay đổi dữ liệu đã xảy ra.

Cho đến nay, cách tiếp cận này đã có hiệu quả và được chứng minh rất thiết thực cho hoàn cảnh của chúng tôi.

Tôi đang tìm kiếm tuy nhiên, rằng tôi là một chút overeager khi tạo các lớp học mới. Các câu hỏi như một lớp học phải là Singleton, hay nên được quản lý theo cách khác, ví dụ như có thể sử dụng một nhà máy, đôi khi trở nên hơi khó khăn, với một chút không chắc chắn.

Tôi phải vẽ đường kẻ bằng đơn? Có một hướng dẫn tốt để quyết định khi nào nên sử dụng Singletons và khi nào phải tránh xa chúng.

Ngoài ra, bất kỳ ai cũng có thể giới thiệu một cuốn sách hay về các mẫu thiết kế?

Answer 1

Điều quan trọng cần nhớ là các mẫu thiết kế chỉ là một công cụ giúp bạn hiểu các khái niệm trừu tượng. Một khi bạn có sự hiểu biết đó, hạn chế bản thân một cách cụ thể đối với một "công thức" từ một cuốn sách là vô nghĩa và làm tổn thương khả năng viết mã phù hợp nhất cho mục đích của bạn. Điều đó nói rằng, đọc sách như GoF sẽ giới thiệu cho bạn nhiều cách để suy nghĩ về các vấn đề để khi thời gian đến để thực hiện một cái gì đó của riêng bạn, bạn sẽ có một tập hợp rộng hơn các quan điểm để tiếp cận vấn đề từ đó.

Trong trường hợp của bạn, nếu sử dụng singleton có ý nghĩa trong mọi trường hợp, sau đó đi thẳng về phía trước.Nếu nó "phù hợp" và bạn phải thực hiện nó theo cách nào đó, thì bạn cần phải đưa ra một giải pháp mới. Buộc một mô hình không hoàn hảo giống như đang ấn một cái chốt hình vuông trong một lỗ tròn.

Giả sử bạn nói "cách tiếp cận này đã có hiệu quả và được chứng minh rất thực tế trong hoàn cảnh của chúng tôi", tôi nghĩ bạn đang làm tốt.

Dưới đây là một số cuốn sách tốt:

Gang of Four Book - cuốn sách cổ điển cho các mẫu thiết kế

Head First Design Patterns - Tôi đã nghe điều này khuyến cáo của một vài người như một sự thay thế

Answer 2

Không, chúng không hẳn là xấu.

Đối với sách, bạn cần bắt đầu bằng số classics.

Answer 3

Singletons không "mà xấu". Nếu bạn có rất nhiều Singletons liên quan và bạn có thể thay thế/củng cố một số người trong số họ bằng cách sử dụng một nhà máy, mà không mất bất cứ điều gì bạn quan tâm, thì đó là khi bạn nên làm như vậy.

Đối với sách, well, there's kind of a canon.

Answer 4

Tôi nghĩ singletons were good.

Answer 5

Người dùng không giết chương trình, người lập trình sẽ giết chương trình.

Giống như bất kỳ cấu trúc lập trình nào, khi được sử dụng phù hợp, bạn sẽ không tự bắn mình vào chân.

Sách được đề xuất là tốt, nhưng chúng không phải lúc nào cũng cung cấp đủ nền tảng đi kèm với trải nghiệm khi bạn có thể chọn sử dụng Singleton.

Trải nghiệm đó chỉ xuất hiện khi bạn thấy Singleton là một lựa chọn tồi khi bạn cần có nhiều phiên bản, và đột nhiên, bạn gặp rất nhiều rắc rối khi tiêm tham chiếu đối tượng ở mọi nơi. Đôi khi tốt hơn là tiếp tục và có tham chiếu đối tượng tại chỗ, nhưng thực tế là bạn đang sử dụng Singleton, tất cả sẽ giúp xác định phạm vi của vấn đề bạn phải đối mặt nếu bạn phải tái cấu trúc nó thành một thiết kế khác . Điều mà tôi tin là một điều rất tốt: tức là chỉ có một lớp học (ngay cả khi được thiết kế kém) cho một số khả năng thấy được ảnh hưởng của sự thay đổi đối với lớp học.

Answer 6

Độc thân chắc chắn không tệ. Họ có sử dụng của họ, một số người trong số họ rất tốt. Singletons có xu hướng bị lạm dụng bởi các nhà phát triển thiếu kinh nghiệm vì nó thường là thiết kế đầu tiên mà họ tìm hiểu, và nó khá đơn giản, vì vậy họ moi nó khắp nơi mà không suy nghĩ về các hàm ý.

Mỗi khi bạn muốn sử dụng một singleton, hãy thử xem xét lý do tại sao bạn đang làm điều đó, và những lợi ích và tiêu cực của việc sử dụng mẫu này là gì.

Singletons thực hiện một cách hiệu quả một tập hợp 'công cụ' có thể truy cập toàn cầu (hoặc dữ liệu hoặc phương pháp) và tôi nghĩ rằng hầu hết mọi người đều đồng ý rằng việc sử dụng quá nhiều biến toàn cầu không phải là một ý tưởng tuyệt vời. Toàn bộ các điểm của các lớp và định hướng đối tượng là nhóm mọi thứ thành các khu vực riêng biệt thay vì chỉ chucking mọi thứ vào một không gian toàn cầu lớn.

Một trong những 'mẫu' mà tôi thấy tôi có xu hướng thích hơn các bộ đơn là truyền các đối tượng cần thiết xuống từ trên cùng. Tôi tạo chúng một lần trong giai đoạn khởi tạo ứng dụng của mình và chuyển chúng qua tất cả các đối tượng cần truy cập vào chúng. Nó bắt chước phần 'đơn sáng tạo' của một mẫu đơn, nhưng không có phần 'toàn cầu'.

Toàn bộ điểm của một singleton là nó dành cho các đối tượng chỉ có 1 nên tồn tại. Bạn đề cập đến một bộ điều khiển dữ liệu của các lớp. Có lẽ xem xét thực sự, có những trường hợp mà một ứng dụng có thể muốn tạo ra 2 bộ lớp kiểm soát dữ liệu, vì vậy có lẽ việc thực thi một singleton về điều này là không hoàn toàn đúng. Thay vào đó, nếu bạn tạo các lớp dữ liệu này trên ứng dụng init và truyền chúng xuống, bạn sẽ chỉ tạo 1 bộ vì đó là ứng dụng hiện tại của bạn yêu cầu, nhưng bạn hãy mở khả năng tại một thời điểm nào đó, nếu bạn cần bộ thứ hai bạn có thể dễ dàng tạo chúng. Ngoài ra, các lớp kiểm soát dữ liệu thực sự có thể truy cập được từ bất kỳ đâu trong ứng dụng. Tôi nghĩ rằng không, thay vào đó họ nên có lẽ chỉ có thể truy cập từ một lớp truy cập dữ liệu cấp thấp hơn.

Một số người đã đề xuất sách GOF. Tôi sẽ nói, vâng đó là một cuốn sách tuyệt vời, nhưng trước tiên hãy thử và tìm một cuốn sách về kiến ​​trúc chung đầu tiên, đọc về thiết kế 2/3/n-tier, đóng gói, trừu tượng và các loại nguyên tắc này trước tiên. Điều này sẽ cung cấp cho bạn một cơ sở vững chắc hơn để hiểu được cách sử dụng thích hợp các mẫu GOF nói về.

[Chỉnh sửa: Thời điểm khác mà một biến thể đơn có thể hữu ích là khi bạn muốn một điểm truy cập đơn lẻ, nhưng chi tiết triển khai thực sự có thể nhiều hơn một điều. Người gọi không cần phải biết, rằng theo yêu cầu của họ đối với đối tượng singleton thực sự được giải quyết dựa trên một số đối tượng có sẵn và một đối tượng được trả về. Tôi đang nghĩ đến một cái gì đó giống như một hồ bơi thread ở đây, nơi việc sử dụng đi, hey, chỉ cần làm cho tôi một chủ đề, tôi cần 1, nhưng tôi không quan tâm cái nào]

Answer 7

Vâng, độc thân là xấu. Họ là xấu bởi vì tất cả họ làm cho bạn là kết hợp hai tài sản, mỗi trong số đó là xấu khoảng 95% thời gian. (Trong đó sẽ có nghĩa là trung bình, độc thân là xấu 99,75% thời gian;))

Một singleton, theo quy định của GOF, là một cấu trúc dữ liệu đó:

1. Tài trợ truy cập toàn cầu đến một đối tượng và
2. Các thực thi chỉ có một thể hiện của đối tượng có thể tồn tại.

Điều đầu tiên thường được coi là điều xấu. Chúng tôi không thích globals. Thứ hai là một chút tinh tế hơn, nhưng nói chung, hầu như không có trường hợp nào đây là hạn chế hợp lý để thực thi.

Đôi khi, chỉ có một ví dụ của một đối tượng. Trong trường hợp bạn chọn chỉ tạo một. Bạn không cần một singleton để thực thi nó.

Và thông thường, ngay cả khi nó "có ý nghĩa" chỉ có một trường hợp, nó sẽ không có ý nghĩa gì cả. Sớm hay muộn, bạn sẽ cần nhiều hơn một logger. Hoặc nhiều hơn một cơ sở dữ liệu. Hoặc bạn sẽ phải tạo lại tài nguyên cho mỗi bài kiểm tra đơn vị của bạn, điều đó có nghĩa là chúng tôi có thể tạo chúng theo ý muốn. Nó sớm loại bỏ tính linh hoạt khỏi mã của chúng tôi, trước khi chúng tôi hiểu hậu quả.

Độc lập ẩn phụ thuộc và tăng khả năng ghép nối (mọi lớp có thể phụ thuộc vào singleton, nghĩa là lớp không thể được sử dụng lại trong các dự án khác trừ khi chúng tôi cũng sử dụng lại tất cả các đơn của chúng tôi). các tham số hàm/constructor), chúng ta không nhận thấy chúng, và thường không nghĩ về nó khi chúng ta tạo ra chúng. Nó rất dễ dàng để chỉ cần kéo trong một singleton, nó hoạt động gần như là một biến địa phương và tất cả, vì vậy chúng tôi có xu hướng sử dụng chúng rất nhiều khi họ đang có. Và điều đó khiến họ gần như không thể loại bỏ một lần nữa. Bạn kết thúc, có lẽ không phải với mã spaghetti, nhưng với đồ thị phụ thuộc spaghetti.Và sớm hay muộn, phụ thuộc chạy trốn của bạn sẽ có nghĩa là những người độc thân bắt đầu phụ thuộc vào nhau, và sau đó bạn nhận được sự phụ thuộc vòng tròn khi người ta cố gắng khởi tạo.

Chúng khiến việc kiểm tra đơn vị trở nên vô cùng khó khăn. (Làm thế nào để bạn thử nghiệm một chức năng mà các cuộc gọi chức năng trên một đối tượng singleton? Chúng tôi không muốn mã singleton thực tế để được thực hiện, nhưng làm thế nào để chúng ta ngăn chặn điều đó?

Vâng, độc thân là xấu.

Đôi khi

Đôi khi, rất rất hiếm khi, bạn có thể có một tình huống khi tạo nhiều thể hiện của một lớp là một lỗi, trong đó có thể không thể (Về trường hợp duy nhất tôi có thể nghĩ đến, và thậm chí điều đó cũng được tạo ra, là nếu bạn đại diện cho một số thiết bị phần cứng. Bạn chỉ có một GPU, vì vậy nếu bạn đang đi để ánh xạ nó tới một đối tượng trong mã của bạn, sẽ có nghĩa là chỉ có một cá thể có thể tồn tại). Nhưng nếu bạn thấy mình trong tình huống như vậy (và một lần nữa, để nhấn mạnh, một tình huống mà nhiều trường hợp gây ra các lỗi nghiêm trọng, không chỉ là một tình huống mà "Tôi không thể nghĩ ra bất kỳ trường hợp sử dụng nào cho nhiều trường hợp"), sau đó thực thi ràng buộc đó, nhưng làm điều đó mà không làm cho đối tượng nhìn thấy được trên toàn cầu.

Mỗi thuộc tính trong số hai thuộc tính này có thể hữu ích, trong một số ít trường hợp. Nhưng tôi không thể nghĩ ra một trường hợp duy nhất mà sự kết hợp của chúng sẽ là một điều tốt.

Thật không may, rất nhiều người đã có ý tưởng rằng "Singletons là hình cầu tương thích OOP." Không, không phải. Họ vẫn gặp phải các vấn đề tương tự như globals, ngoài để giới thiệu một số khác, hoàn toàn không liên quan. Có hoàn toàn không có lý do để thích một singleton trên một toàn cầu cũ đồng bằng.

Answer 8

Google có vẻ là convinced rằng Singletons là một ý tưởng tồi.

Điều đó không có nghĩa là mọi thứ Google làm là hoàn hảo hoặc mọi ý kiến ​​của họ đều là kết thúc của bất kỳ đối số nào, nhưng họ đã đi xa đến mức viết máy dò Singleton này để root chúng. Làm cho tâm trí của riêng bạn.

Answer 9

Theo ý kiến ​​của tôi, việc sử dụng Singletons trực tiếp báo hiệu lỗi thiết kế. Lý do đơn giản là chúng cho phép người ta bỏ qua các cơ chế tạo và phá hủy đối tượng bình thường được xây dựng trong C++. Nếu một đối tượng cần tham chiếu đến một đối tượng khác, nó cần phải truyền tham chiếu đến nó khi xây dựng hoặc tạo một thể hiện mới của nó trong nội bộ. Nhưng khi bạn sử dụng một singleton bạn rõ ràng obfuscating chu kỳ tạo ra và teardown. Một vấn đề liên quan là nó là vô cùng khó khăn để kiểm soát tuổi thọ của một singleton. Kết quả là, nhiều gói bao gồm việc triển khai singleton chung cũng bao gồm các trình quản lý lâu dài đối tượng clunky và tương tự. Đôi khi tôi tự hỏi nếu những điều này không tồn tại chỉ đơn giản là để quản lý các singletons.

Về cơ bản, nếu bạn cần sử dụng một đối tượng ở nhiều nơi, nó sẽ được tạo rõ ràng tại điểm chung cao nhất trong ngăn xếp và sau đó được chuyển xuống thông qua tham chiếu đến tất cả những người sử dụng nó. Đôi khi mọi người sử dụng Singletons vì họ gặp vấn đề khi chuyển nhiều arg tới các luồng mới, nhưng không rơi cho điều này, xác định rõ ràng luồng của bạn và chuyển chúng đến luồng mới theo cách tương tự. Bạn sẽ thấy rằng chương trình của bạn chảy sạch hơn nhiều và không có bất ngờ khó chịu do phụ thuộc khởi tạo tĩnh hoặc teardownous teardown.

Answer 10

Chúng tôi đã bắt đầu một dự án mà về cơ bản chúng ta đang đối mặt với cùng một câu hỏi, đó là cách truy cập vào mô hình và đặc biệt là phần tử gốc của nó.Dự án không phải là một ứng dụng Flex, nhưng là một trò chơi! ứng dụng web, nhưng điều đó không quan trọng.

Có một đối tượng đơn duy nhất trong hệ thống là tốt, vấn đề là cách truy cập vào. Vì vậy, các cuộc tranh luận về singleton có liên quan đến khái niệm của nghịch đảo phụ thuộc (DI), và làm thế nào để có được các đối tượng.

Những lập luận chính DI như sau:

• testability và chế giễu
• tách instantiation đối tượng từ việc sử dụng (có thể dẫn đến quản lý vòng đời)
• tách mối quan tâm

Các phương pháp có thể có cho DI là (xem cổ điển article từ Fowler):

• để vượt qua đối tượng xung quanh trong phương pháp thông số
• định vị dịch vụ
• DI khuôn khổ

Theo quan điểm này, mô hình singleton chỉ là một loại định vị dịch vụ, ví dụ Model.getInstance().

Nhưng để cung cấp sự linh hoạt tối đa khi đối mặt với các thay đổi trong tương lai, tham chiếu đến đối tượng duy nhất phải là được thông qua khoảng càng nhiều càng tốt và chỉ thu được Model.getInstance() khi cần. Điều này cũng sẽ mang lại mã sạch hơn.

Answer 11

nhà phát triển phần mềm dường như khá đồng đều chia thành hai phe, tùy thuộc vào việc họ ủng hộ một phong cách mã hóa lý tưởng hoặc một thực tế một:

• lý tưởng: Never sử dụng Singleton pattern.
• Thực dụng: Tránh mẫu đơn.

Cá nhân, tôi ủng hộ cách tiếp cận thực dụng. Đôi khi nó có ý nghĩa để phá vỡ các quy tắc, nhưng chỉ khi bạn thực sự hiểu những gì bạn đang làm và sẵn sàng chấp nhận những rủi ro liên quan. Nếu bạn có thể trả lời "có" cho các câu hỏi bên dưới về trường hợp sử dụng cụ thể của bạn, mẫu đơn có thể mang lại một số lợi ích thiết thực.

• Singleton có nằm ngoài ứng dụng của bạn không? Cơ sở dữ liệu, các dịch vụ xếp hàng và ESB là tất cả các ví dụ macro hoàn toàn hợp lệ của mẫu đơn.
• KISS: Bạn có toàn bộ ứng dụng giới hạn trong 2-3 nội dung đơn?
• KHI: Các trình đơn đó có phải là toàn cầu vốn có và do đó sẽ dẫn đến việc phải trích dẫn các tham chiếu vào hầu hết mọi đối tượng trong ứng dụng của bạn? (ví dụ: trình ghi nhật ký hoặc hòa giải thành phần)?
• Người độc thân của bạn có chỉ phụ thuộc vào nhau và/hoặc môi trường hoạt động không?
• Bạn đã đảm bảo trình tự khởi động và tắt phù hợp cho từng singleton, bao gồm cả cân nhắc quản lý bộ nhớ?Ví dụ, một hồ bơi thread kiểu "Grand Central" có thể cần phải có các phương thức Run() và Shutdown() trong main() để các tác vụ được bảo đảm chỉ chạy khi các đối tượng chúng hoạt động ở trạng thái hợp lệ.

Answer 12

Tôi biết đây là một chủ đề cũ nhưng không ai có vẻ đề cập đến mô hình thực tế phù hợp với những gì OP đang cố gắng thực hiện. Những gì tôi tin rằng ông đang mô tả một nhu cầu được gọi là Mediator Pattern. SourceMaking là một trang web tuyệt vời cho việc học/tham khảo loại thông tin này. Chắc chắn tôi đi đến nơi để giới thiệu mọi người với các mẫu phần mềm. Ngoài ra, nó thường là một ý tưởng tốt để không mua vào khái niệm rằng bất kỳ mô hình thiết kế nhất thiết phải là tốt hay xấu. Tất cả họ đều có sử dụng của họ, nó chỉ học hỏi khi nào và ở đâu để sử dụng chúng đó là thủ thuật. Những người nhà nước không bao giờ sử dụng Singletons, với tôi, không hiểu tính hữu ích của họ.