Kế thừa vs Thành phần

Tôi kiếm tiền bằng C # Nói chung bằng ngôn ngữ đó, tôi muốn tách mọi thứ lên các tầng trời bằng giao diện. Điều này đã phục vụ tốt cho tôi trong mã doanh nghiệp nhưng khi viết trò chơi bằng C #, tôi thấy mình có xu hướng kế thừa do có thể xác định một số hành vi mặc định cho các lớp cơ sở. Mặc dù vậy, tôi cảm thấy bẩn khi làm điều này, giống như tôi không vâng lời một vị thần kiến ​​trúc nào đó đã từng nói "ủng hộ sáng tác hơn thừa kế". Tôi biết nó không phải là màu đen và trắng nhưng tôi cũng cảm thấy như tôi có thể sử dụng các giao diện với công việc nhiều hơn một chút và đạt được điều tương tự.

Người khác làm gì? Kế thừa là cách tiếp cận phù hợp cho các trò chơi hay tôi nên cấu trúc lại trong một số giao diện?

Kế thừa trong các trò chơi thực sự là một trong những điều tồi tệ nhất bạn có thể làm - đặc biệt là liên quan đến các thực thể. Đọc này để biết tại sao. Sáng tác trên sự kế thừa sẽ đưa bạn đi một chặng đường dài với các trò chơi. Đối với các khu vực khác trong động cơ của bạn, nó không thực sự quan trọng. Ví dụ: bạn đang thực hiện cuộc gọi đến một loại dịch vụ mạng bên ngoài, sau đó bạn có thể kế thừa một loại Dịch vụ chung chung, vd. HTTPService và SocketService - rất nhiều như trong các ứng dụng doanh nghiệp bạn đã quen.

Trừ khi trò chơi của bạn thực sự đơn giản, bạn sẽ muốn sử dụng kiến ​​trúc thực thể dựa trên thành phần (CBE). Ý tưởng chung là với các thực thể, lý do chúng thường được sáng tác thay vì được kế thừa là vì bạn không thể biết cho đến khi thực hiện các khả năng mà một thực thể nhất định sẽ có. Ví dụ, đưa tàu của người chơi vào một game bắn súng không gian. Bạn không biết cho đến một lúc nào đó trong quá trình chơi trò chơi, vũ khí, áo giáp, hệ thống (tức là linh kiện) mà người chơi sẽ nhặt, mua, bán, mất, đã phá hủy, v.v ... Vì vậy, cách duy nhất để mô hình hóa điều này là thông qua thành phần đối tượng. Điểm cộng trong kịch bản này là bạn cũng có thể có những kẻ thù hoàn toàn có thể tùy chỉnh, được xây dựng theo cùng một cách, thay vì những kẻ thù luôn giống hệt nhau mỗi khi bạn nhìn thấy loại kẻ thù đó. Vì vậy, với CBE, bạn có thể thấy một Người vận chuyển Sao Hỏa và nghĩ, "Ah nó chỉ có những tia laser nhỏ, tôi sẽ gỡ nó xuống", và điều đó thường đúng nhưng khi bạn ở trong phạm vi đột nhiên bạn nhận ra nó có một cái mông lớn súng giun. Bất ngờ bất ngờ!

Thành phần hóa là loại bỏ khớp nối ngầm của logic, và đó là TỐT.

Đối với những người nói tiếng Đức, một cuốn sách thú vị: http://www.amazon.com/Architektur-Kerns-einer-Game-Engine-Imcellenceierung/dp/3639324471/ref=sr_1_1?ie=UTF8&qid=1314875533&sr=8-1

Xem xét kỹ hơn về thời điểm và lý do sử dụng kiến ​​trúc nào có thể được tìm thấy ở đây: /programming/1901251/component-basing-game-engine-design

Đối với bản thân tôi, tôi quyết định kiến ​​trúc của mình tùy thuộc vào quy mô của dự án và khả năng mở rộng hoặc sử dụng lại mã. Tại sao đầu tư hàng giờ vào kiến ​​trúc của một dự án siêu nhỏ mà không có cơ hội bạn sử dụng lại mã? Đồng thời bạn có thể hoàn thành dự án.

Thành phần so với Thành phần Các thành phần là những thứ ưa thích thú vị nhưng trong hầu hết các dự án / kiến ​​trúc, thành phần cũng sẽ thực hiện công cụ (không có chi phí dựa trên thành phần). Nó phụ thuộc vào những gì hệ thống thành phần của bạn có thể cung cấp thành phần đó không thể.

Ví dụ: đưa tàu của người chơi vào một game bắn súng không gian. Bạn không biết cho đến một lúc nào đó trong quá trình chơi trò chơi, vũ khí, áo giáp, hệ thống (tức là linh kiện) mà người chơi sẽ nhặt, mua, bán, mất, đã phá hủy, v.v ... Vì vậy, cách duy nhất để mô hình hóa điều này là thông qua thành phần đối tượng.

tất cả những gì có thể mà không có các thành phần từ lâu