Làm thế nào để tránh mẫu singleton cho Trình lập lịch sự kiện?

Tôi muốn tạo một lịch trình Sự kiện cho Trò chơi của mình, về cơ bản tôi muốn có thể lên lịch kích hoạt Sự kiện Trò chơi. Đây có thể là trình kích hoạt một lần hoặc trình kích hoạt định kỳ (sự kiện kích hoạt "E_BIG_EXPLOSION" trên cơ sở 5 giây ...).

Thật hấp dẫn khi nghĩ rằng đây có thể là một nơi tốt để sử dụng Singleton, nhưng những người độc thân có thể khá xấu xa và họ có xu hướng lây lan như một căn bệnh ... vì vậy tôi cố gắng tránh chúng bằng mọi giá.

Thiết kế nào bạn sẽ đề xuất để tránh việc sử dụng singleton trong trường hợp này?

Bạn nên có một bộ giao diện được xác định rõ ràng được phép truyền hoặc nhận tin nhắn - cung cấp cho chúng một tham chiếu đến EventScheduler là không đáng kể. Nếu không, hoặc nếu bạn cảm thấy điều đó liên quan đến việc chuyển lịch trình sự kiện sang "quá nhiều" loại khác nhau, thì bạn có thể gặp vấn đề về thiết kế lớn hơn (một sự phụ thuộc bừa bãi, mà những người độc thân có xu hướng làm trầm trọng thêm, không giải quyết được ).

Hãy nhớ rằng trong khi kỹ thuật chuyển bộ lập lịch tới các giao diện cần nó là một dạng " tiêm phụ thuộc ", thì trong trường hợp này bạn không tiêm một phụ thuộc mới . Đây là một phụ thuộc mà bạn đã có trong hệ thống, nhưng bây giờ bạn đang biến nó thành một phụ thuộc rõ ràng (so với sự phụ thuộc ngầm của một người độc thân). Theo nguyên tắc thông thường, các phụ thuộc rõ ràng sẽ được ưu tiên hơn vì chúng có nhiều tài liệu hơn.

Bạn cũng có khả năng linh hoạt hơn bằng cách tách riêng người tiêu dùng của lịch trình sự kiện với nhau (vì chúng không nhất thiết phải gắn với cùng một lịch trình), có thể hữu ích để thử nghiệm hoặc mô phỏng thiết lập máy khách / máy chủ cục bộ hoặc một số tùy chọn khác - bạn có thể không cần các tùy chọn khác này, nhưng bạn đã không nỗ lực để hạn chế một cách giả tạo bản thân khỏi chúng, đó là một lợi thế.

EDIT: Tất cả những gì tôi muốn nói khi tôi nói về việc vượt qua lịch trình xung quanh là thế này: nếu bạn có một thành phần trò chơi nào đó chịu trách nhiệm đối phó với sự va chạm, thì có lẽ nó được tạo ra thông qua một nhà máy phản ứng va chạm là một phần của lớp vật lý của bạn. Nếu bạn xây dựng nhà máy với một cá thể lập lịch, thì nó có thể chuyển thể hiện đó cho bất kỳ người trả lời nào mà nó tạo ra, sau đó có thể sử dụng nó để nâng cao các sự kiện (hoặc có thể đăng ký các sự kiện khác).

class CollisionResponderFactory {
  public CollisionResponderFactory (EventScheduler scheduler) {
     this.scheduler = scheduler;
  }

  CollisionResponder CreateResponder() {
    return new CollisionResponder(scheduler);
  }

  EventScheduler scheduler;
}

class CollisionResponder {
  public CollisionResponder (EventScheduler scheduler) {
    this.scheduler = scheduler;
  }

  public void OnCollision(GameObject a, GameObject b) {
    if(a.IsBullet) {
      scheduler.RaiseEvent(E_BIG_EXPLOSION);
    }
  }

  EventScheduler scheduler;
}

Đây rõ ràng là một ví dụ cực kỳ đơn giản và đơn giản vì tôi không biết mô hình đối tượng trò chơi của bạn là gì; tuy nhiên nó minh họa làm cho sự phụ thuộc vào bộ lập lịch sự kiện rõ ràng và cho thấy một số tiềm năng để đóng gói thêm (bạn không nhất thiết phải chuyển người trả lời lên lịch nếu họ giao tiếp với hệ thống phản ứng va chạm ở cấp độ cao hơn ở cùng cấp độ khái niệm như Nhà máy xử lý các loại hạt và bu lông gây ra sự kiện thông qua bộ lập lịch. Điều này sẽ cách ly từng triển khai phản hồi riêng lẻ với các chi tiết triển khai của hệ thống điều phối sự kiện, chẳng hạn như sự kiện cụ thể nào sẽ xảy ra khi va chạm, có thể lý tưởng cho hệ thống của bạn - - hay không).

Một người điều phối sự kiện là một trong những trường hợp mà một người độc thân không phải là ý tưởng tồi tệ nhất trên thế giới, nhưng tôi hoan nghênh bạn vì đã cố gắng tránh nó. Bạn có thể tìm thấy một số ý tưởng ở đây .

Tôi cũng có xu hướng tránh singletons nhưng có một vài đối tượng có ý nghĩa nhất là singletons và một hệ thống nhắn tin trung tâm là một trong số đó. Bất chấp những lời tán tỉnh mà tôi đã nghe thấy, singletons chắc chắn tốt hơn nhiều so với các biến / hàm toàn cầu vì bạn luôn phải cố tình giải quyết nó (so với các giá trị toàn cầu chỉ xuất hiện một cách kỳ diệu ngoài không khí).

Cuối cùng, mỗi người gửi và người nhận tin nhắn phải có một số điểm giao nhau, và tốt hơn hết là giữ cho các đối tượng của bạn tách rời bằng cách chia sẻ một thông tin chung bởi mọi thứ thay vì mỗi người gửi tin nhắn của bạn biết trực tiếp về người nhận tin nhắn.

Mặc dù tôi chắc chắn rằng một số kiến ​​trúc khác có thể được tạo ra cho hệ thống sự kiện của bạn, nhưng đối với tôi, có vẻ như thật lãng phí khi nghĩ quá nhiều về nó, đặc biệt khi sử dụng một hệ thống sự kiện đã là một chiến thắng lớn khi không sử dụng nó.

EDIT: Đối với ví dụ cụ thể của bạn về một sự kiện nổ được gửi trên một bộ kích hoạt định kỳ, tôi có thể sẽ có các sự kiện được gửi trong một số vật thể khác (như súng tháp pháo hoặc bất cứ thứ gì gây ra những vụ nổ đó) chứ không phải trong hệ thống sự kiện trung tâm. Tuy nhiên, những sự kiện đó vẫn sẽ được gửi đến hệ thống sự kiện trung tâm.