Không nhiều kế thừa giải quyết tất cả các vấn đề mà các hệ thống thực thể làm?

Câu hỏi khá tự giải thích: không thừa kế nhiều giải quyết tất cả các vấn đề mà hệ thống thực thể cũng giải quyết?

Tôi chỉ nhớ một thuật ngữ gọi là "thừa kế nhiều lần", và điều đó dường như giải quyết được rất nhiều vấn đề đầy hơi mà thừa kế cổ điển áp đặt.

Không, nhiều kế thừa không giải quyết được tất cả các vấn đề giống như các hệ thống thực thể: hệ thống thực thể và nhiều kế thừa là hai điều rất khác nhau. Bạn có thể xây dựng một hệ thống thực thể có hoặc không có nhiều kế thừa và tương tự bạn có thể sử dụng nhiều kế thừa mà không cần xây dựng một hệ thống thực thể.

Theo truyền thống, các hệ thống thực thể tập trung vào thành phần được phát triển vì mong muốn tránh xa sự kế thừa nặng nề dưới bất kỳ hình thức nào, thay vào đó nhắm đến thành phần . Có đủ tài liệu và thảo luận ở đâu đó về câu ngạn ngữ này, ví dụ như về các lập trình viên SE hoặc SO , và câu hỏi lớn hơn về lý do tại sao thích sáng tác lại là một chủ đề không phù hợp để phát triển trò chơi. Tuy nhiên, trong ngắn hạn, đó là một cách tiếp cận có xu hướng cho vay để cải thiện khả năng biến đổi và duy trì.

Câu trả lời của Josh rất tuyệt, nhưng tôi muốn thêm:

Một trong những tính năng thú vị nhất của Thực thể / Thành phần là cách điều khiển dữ liệu trong đó mọi "thứ" trong trò chơi của bạn được tạo và quản lý. Từ những gì tôi đã thấy, một khi bạn có một thư viện đẹp về các loại thành phần và hệ thống được tạo, bạn có thể xây dựng bất cứ thứ gì với sửa đổi mã tối thiểu. (Lưu ý: tối thiểu! = 0 )

Bằng cách xác định trò chơi của bạn về mặt hành vi và tạo cho mình khả năng sửa đổi các hành vi đó một cách nhanh chóng - trong thời gian chạy, trong khi khởi tạo bằng cách tải chúng từ tập lệnh hoặc cơ sở dữ liệu, v.v. - bạn mở ra cả một thế giới khả năng mới. Bạn muốn xem tại sao bóng của bạn không hạ cánh ở nơi bạn mong đợi? Thêm một thành phần máy ảnh / POV cho ánh sáng của bạn.

Thực thể / thành phần cho phép bạn xây dựng bất cứ thứ gì bạn muốn, miễn là bạn đã tạo các khối.

Ngoài ra, nhiều kế thừa gây ra vấn đề tương tự như thừa kế đơn. Khi bạn thêm một thuộc tính hoặc hành vi trong hệ thống phân cấp, nó sẽ lan truyền. Miễn là bạn đang thực hiện phân cấp sâu, bạn sẽ gặp phải tình huống bạn mang trọng lượng không cần thiết, sao chép mã hoặc giải quyết xung đột. Hầu hết điều đó có thể tránh được khi bạn tưởng tượng trò chơi của mình là dữ liệu.

Tôi mới bắt đầu chơi với thứ này trong vài tuần qua, nhưng tôi rất ấn tượng về những điều đơn giản đã trở thành. Đó không phải là viên đạn bạc - Tôi đã chạy qua một vài trường hợp trong đó gắn lambda vào một bộ phận là cách sạch nhất và phù hợp nhất để giải quyết vấn đề - nhưng đó là một mô hình khá tuyệt vời, nếu bạn có thể gọi nó là như vậy.

Trên một lưu ý hơi liên quan: một trong những trình tạo bảo trì lớn, nhàm chán trong các ứng dụng tập trung vào dữ liệu (trang web, v.v.) đang ánh xạ các đối tượng phân cấp vào cơ sở dữ liệu quan hệ. Chúng tôi đã có rất nhiều giải pháp tiện lợi xung quanh, nhưng cuối cùng tất cả chúng đều được thiết kế để san phẳng hệ thống phân cấp. Thay vì xây dựng mô hình của bạn để nó phục vụ cho mục đích của ứng dụng, bạn kết thúc thỏa hiệp giữa một hệ thống phân cấp hiệu quả và biểu diễn quan hệ logic. Tôi đã từng chơi đùa với ý tưởng xây dựng lại một hệ thống phân cấp khá lớn trong một trong các ứng dụng của mình dưới dạng một hệ thống thực thể / thành phần - bỏ cấu trúc phân cấp và biến cơ sở dữ liệu thành Tiêu chuẩn Vàng cho phần còn lại của việc triển khai - và nó đầy hứa hẹn.

Khi bạn tích hợp các khả năng như tạo mã / bộ đệm mã động có thể giải quyết các vấn đề về hiệu năng, bạn sẽ có một kiến ​​trúc logic nhanh, linh hoạt, có thể nhận ra mục tiêu mã có thể sử dụng lại của OOP theo cách tốt hơn nhiều.