Các trò chơi bán lẻ có sử dụng đảo ngược điều khiển và điều khiển phụ thuộc vào cộng đồng hay không?

Nhiều nhà phát triển phần mềm siêng năng hơn mà tôi biết đang chuyển sang nghịch đảo kiểm soát và tiêm phụ thuộc để xử lý các tham chiếu đến các đối tượng. Xuất phát từ góc độ trò chơi Flash, tôi không biết tất cả các hãng phim AAA, vì vậy: chúng có được sử dụng trong thế giới trò chơi bán lẻ không?

Bạn gọi nó là 'phát triển phần mềm siêng năng', tôi gọi đó là 'sự áp đảo đau đớn'. Điều đó không có nghĩa là sự đảo ngược của kiểm soát là xấu - trên thực tế, định nghĩa cơ bản của nó là tốt - nhưng sự phổ biến của toàn bộ khuôn khổ và phương pháp làm việc để đạt được tất cả điều này là hơi điên rồ, đặc biệt là kết hợp với cách mọi người đang dọn rác giao diện hoàn toàn tốt và sạch sẽ để có thể tiêm các thành phần có thể hoán đổi cho nhau mà 99% thời gian bạn sẽ không bao giờ trao đổi. Đó là thứ chỉ có thể bắt nguồn từ môi trường doanh nghiệp Java và tôi rất vui vì nó không có nhiều chỗ đứng ở nơi khác.

Thông thường, đối số là ngay cả khi bạn không trao đổi các thành phần, bạn muốn có thể kiểm tra chúng một cách cô lập với các đối tượng giả và tương tự. Tuy nhiên, tôi e rằng tôi sẽ không bao giờ mua lập luận rằng nó đáng để làm đầy và làm phức tạp một giao diện để có thể kiểm tra nó tốt hơn. Kiểm tra chứng minh một điều duy nhất - rằng các thử nghiệm của bạn hoạt động. Mặt khác, các giao diện sạch và tối thiểu đi một chặng đường dài để chứng minh rằng mã của bạn hoạt động.

Vì vậy, câu trả lời ngắn gọn: có, nhưng không phải theo cách bạn đang nghĩ. Đôi khi, khi bạn cần hành vi có thể hoán đổi cho nhau, bạn sẽ chuyển một đối tượng đến một nhà xây dựng chỉ đạo một phần hành vi của đối tượng mới. Đó là về nó.

Mô hình chiến lược , Thành phần , Tiêm phụ thuộc , tất cả đều liên quan rất chặt chẽ.

Vì Mô hình Chiến lược là một hình thức của Dependency Injection, nếu bạn xem các công cụ như Unity chẳng hạn, chúng hoàn toàn dựa trên nguyên tắc này. Việc sử dụng Thành phần (Mẫu chiến lược) của họ được nhúng sâu vào toàn bộ công cụ của họ.

Một trong những lợi ích chính ngoài việc tái sử dụng các thành phần là tránh các hệ thống phân cấp lớp sâu đáng sợ.

Dưới đây là một bài viết của Mick West , người nói về cách ông giới thiệu loại hệ thống này vào loạt trò chơi Tony Hawk của Neversoft.

Phát triển thứ bậc của bạn

Cho đến những năm gần đây, các lập trình viên trò chơi đã liên tục sử dụng một hệ thống phân cấp lớp sâu để đại diện cho các thực thể trò chơi. Làn sóng đang bắt đầu chuyển từ việc sử dụng hệ thống phân cấp sâu này sang nhiều phương thức khác nhau tạo thành một đối tượng thực thể trò chơi như một tập hợp của các thành phần ...

Dường như có rất nhiều nhầm lẫn về mẫu Inversion of Control (IoC). Một số người đã đánh đồng nó với Mô hình chiến lược hoặc Mô hình thành phần, nhưng những so sánh này không thực sự nắm bắt được IoC là gì. IoC thực sự là về cách thu được một sự phụ thuộc. Tôi sẽ cho bạn một ví dụ:

class Game {
    void Load() {
        this.Sprite.Load(); // loads resource for drawing later
    }
}

class Sprite {
    void Load() {
        FileReader reader = new FileReader("path/to/resource.gif");
        // load image from file
    }
}

Ở trên, rõ ràng Sprite.Loadcó sự phụ thuộc vào a FileReader. Khi bạn muốn kiểm tra phương pháp bạn cần như sau:

1. Một hệ thống tập tin tại chỗ
2. Một tệp thử nghiệm để tải từ hệ thống tệp
3. Khả năng kích hoạt các lỗi hệ thống tệp phổ biến

Hai cái đầu tiên là rõ ràng, nhưng nếu bạn muốn đảm bảo rằng việc xử lý lỗi của bạn hoạt động như mong đợi, bạn cũng thực sự cần số 3. Trong cả hai trường hợp, bạn có khả năng làm chậm các bài kiểm tra của mình xuống một chút vì bây giờ chúng cần phải vào đĩa và bạn có thể làm cho môi trường kiểm tra của bạn phức tạp hơn.

Mục tiêu của IoC là tách rời việc sử dụng hành vi từ việc xây dựng nó. Lưu ý cách này khác với mẫu Chiến lược. Với mẫu Chiến lược, mục tiêu là gói gọn một đoạn hành vi có thể sử dụng lại để bạn có thể dễ dàng mở rộng nó trong tương lai; nó không có gì để nói về cách các chiến lược được xây dựng.

Nếu chúng ta viết lại Sprite.Loadphương thức trên, chúng ta có thể sẽ kết thúc bằng:

class Sprite {
    void Load(IReader reader) {
        // load image through reader
    }
}

Bây giờ, chúng tôi đã tách rời việc xây dựng của người đọc từ việc sử dụng nó. Do đó, có thể trao đổi trong một trình đọc thử trong khi thử nghiệm. Điều này có nghĩa là môi trường kiểm tra của bạn không còn cần một hệ thống tệp, tệp kiểm tra và có thể dễ dàng mô phỏng các sự kiện lỗi.

Lưu ý rằng tôi đã làm hai điều trong bản viết lại của mình. Tôi đã tạo một giao diện IReadergói gọn một số hành vi - tức là đã triển khai mẫu Chiến lược. Ngoài ra, tôi chuyển trách nhiệm tạo độc giả phù hợp sang một lớp khác.

Có lẽ chúng ta không cần một tên mẫu mới để mô tả ở trên. Nó tạo cho tôi một sự pha trộn giữa các mẫu Chiến lược và Nhà máy (đối với các thùng chứa IoC). Điều đó đang được nói, tôi không chắc chắn về lý do mọi người phản đối mô hình này vì rõ ràng nó giải quyết được một vấn đề thực sự và chắc chắn, đối với tôi điều này không rõ ràng với Java.

Tôi có thể nói rằng nó là một công cụ trong số rất nhiều, và nó được sử dụng đôi khi. Như tenpn đã nói, bất kỳ phương pháp nào giới thiệu vtables (và nói chung là bất kỳ sự gián tiếp bổ sung nào) đều có thể bị phạt hiệu năng, nhưng đây là điều mà chúng ta chỉ nên lo lắng về mã cấp thấp. Đối với mã cấu trúc cấp cao không thực sự là vấn đề và IoC có thể có lợi ích tích cực. Bất cứ điều gì để giảm sự phụ thuộc giữa các lớp và làm cho mã của bạn linh hoạt hơn.

Gotta đồng ý với Kylotan về điều này. "Tiêm phụ thuộc" là một giải pháp Java xấu cho lỗ hổng khái niệm Java xấu xí và lý do duy nhất bất cứ ai nhìn vào nó bằng các ngôn ngữ khác là vì Java trở thành ngôn ngữ đầu tiên cho nhiều người, khi nó thực sự không nên.

Mặt khác, kiểm soát đảo ngược là một ý tưởng hữu ích đã có từ lâu và rất hữu ích khi được thực hiện đúng. (Không phải cách Java / Dependency Injection.) Trên thực tế, bạn có thể làm điều đó mọi lúc nếu bạn đang làm việc trong một ngôn ngữ lập trình lành mạnh. Khi tôi lần đầu tiên đọc về toàn bộ điều "IOC" này, mọi người đều xôn xao, tôi hoàn toàn bị choáng ngợp. Inversion of Control không gì khác hơn là chuyển một con trỏ hàm (hoặc con trỏ phương thức) đến một thường trình hoặc đối tượng để giúp tùy chỉnh hành vi của nó.

Đây là một ý tưởng đã có từ những năm 1950. Nó nằm trong thư viện chuẩn C (qsort hiện lên trong tâm trí) và nó ở khắp mọi nơi trong Delphi và .NET (xử lý sự kiện / đại biểu). Nó cho phép mã cũ gọi mã mới mà không cần biên dịch lại mã cũ và nó được sử dụng mọi lúc trong các công cụ trò chơi.

Không theo kinh nghiệm của tôi. Đó là một sự xấu hổ, vì mã trò chơi cần phải rất dễ thích nghi, và những cách tiếp cận này chắc chắn sẽ giúp ích.

Tuy nhiên, phải nói rằng cả hai phương thức đều có thể, trong C ++, giới thiệu các bảng ảo mà trước đó không có phương thức nào, mang lại cho chúng một hiệu năng phù hợp.

Tôi không phải là một nhà phát triển game chuyên nghiệp và chỉ thử triển khai IoC trong C ++ một lần, vì vậy đây chỉ là suy đoán.

Tuy nhiên, tôi nghi ngờ các nhà phát triển trò chơi sẽ nghi ngờ về IoC bởi vì điều đó có nghĩa là:

1 / thiết kế nhiều giao diện và nhiều lớp nhỏ

2 / có khá nhiều cuộc gọi chức năng bị ràng buộc gần đây

Bây giờ, nó có thể là một sự trùng hợp ngẫu nhiên, nhưng cả hai đều có xu hướng phức tạp hơn một chút và / hoặc có vấn đề đối với các màn trình diễn trong C ++ (được sử dụng rộng rãi trong trò chơi, phải không?) So với Java, nơi IoC trở nên phổ biến (Có lẽ là bởi vì nó tương đối dễ thực hiện, giúp mọi người thiết kế hệ thống phân cấp đối tượng saner và vì một số người tin rằng nó có thể biến việc viết một ứng dụng trong Java thành viết một ứng dụng bằng XML, nhưng đó là một cuộc tranh luận khác: P)

Tôi quan tâm đến các bình luận nếu điều đó không có ý nghĩa gì cả;)