Làm cách nào để áp dụng Thiết kế hướng dữ liệu với lập trình hướng đối tượng? [đóng cửa]


17

Tôi đã đọc rất nhiều bài viết về Thiết kế hướng dữ liệu (DOD) và tôi hiểu nó nhưng tôi không thể thiết kế hệ thống Lập trình hướng đối tượng (OOP) với DOD trong tâm trí, tôi nghĩ rằng giáo dục OOP của tôi đang chặn tôi. Làm thế nào tôi nên suy nghĩ để trộn hai? Mục tiêu là có một giao diện OOP đẹp trong khi sử dụng DOD đằng sau hậu trường.

Tôi cũng thấy điều này nhưng không giúp được gì nhiều: /programming/3872354/how-to-apply-dop-and-keep-a-nice-user-interface


3
Bạn cần phải đăng một cái gì đó nhiều hơn nữa cụ thể (và trò chơi có liên quan), câu hỏi này là xa quá chung chung.
DeadMG

Bạn nói đúng, nhưng tôi chưa thấy điều này được thảo luận trong các lĩnh vực khác ngoài lập trình trò chơi.
Pombal

4
@DeadMG: Tôi chưa bao giờ thấy thuật ngữ thiết kế hướng dữ liệu được sử dụng bên ngoài phát triển trò chơi, ngoại trừ khi đề cập đến các thực tiễn bắt nguồn từ phát triển trò chơi. Nếu bạn đang nghĩ về thiết kế dựa trên dữ liệu, đó không phải là điều tương tự.

Câu trả lời:


16

Tôi muốn nói rằng blog của Noel Llopis có lẽ là hướng dẫn tốt nhất cho sự kết hợp giữa lập trình hướng đối tượng và thiết kế hướng dữ liệu. Anh ta là một trong những người khởi xướng thuật ngữ DOD, là một lập trình viên C ++ mạnh mẽ và đã viết rất nhiều về phong cách của anh ta và cách anh ta tận dụng các tính năng OO của C ++.

Tôi đoán nếu tôi gọi ra các yếu tố chính của việc kết hợp chúng, theo Noel:

  • Sử dụng POD và các chức năng không phải thành viên, không phải bạn bè càng nhiều càng tốt. Các chức năng không phải thành viên, không phải bạn bè cải thiện việc đóng gói và là một phần quan trọng của định hướng dữ liệu vì chúng giữ dữ liệu, dữ liệu.
  • Tránh lưu trữ trạng thái "tạm thời" trên các đối tượng của bạn. Trạng thái tạm thời làm tắc nghẽn dữ liệu của bạn. Nếu bạn cần lưu trữ một cái gì đó (ví dụ về hiệu năng) thì nó thuộc về một lớp mới, với các hàm không phải là thành viên không liên kết giữa hai loại, không phải là mối quan hệ giữa-và cũng không có.
  • Tránh các đối tượng có thể ở trạng thái A hoặc trạng thái B. Thích chuyển đổi giữa hai đối tượng, một trong số đó là A và một trong số đó là B.
  • Tránh đa hình, tránh các chức năng ảo, tránh các mẫu, tránh bất cứ điều gì làm cho dữ liệu của bạn có sự xuất hiện cú pháp của sự giống nhau hơn là sự giống nhau thực tế .

Một tên tuổi lớn khác trong tuyên truyền của Bộ Quốc phòng ngay bây giờ là Mike Acton của Insomniac, nhưng đọc những gì anh ấy viết tôi sẽ nói rằng anh ấy không thực sự ủng hộ OO (hoặc chống OO, miễn là nó vẫn hướng đến dữ liệu).


Cảm ơn bạn đã trả lời nhưng những gì bạn đang nói là những gì tôi nên làm để sử dụng DOD, chứ không phải làm thế nào tôi có thể sử dụng OO với nó. Tôi đã đọc blog của Noel, những lời tán dương của Mike Acton (: D), các ấn phẩm của DICE trong số những người khác và tôi hiểu cách sử dụng DOD, không phải với OO trộn lẫn.
Pombal

2
Bạn nghĩ OO là gì? Tôi sẽ gọi hầu hết mã OO của Noel, chẳng hạn - vẫn còn các lớp và trường hợp, vẫn có công văn dựa trên kiểu, vẫn có thể có sự kế thừa (định nghĩa POD của C ++ 0x đã được thay đổi để cho phép điều này). Một mô hình vẫn có vấn đề bắt đầu với dữ liệu, thay vì hoạt động.

Ví dụ, đa hình là một phần quan trọng của OOP, giống như trạng thái của đối tượng. Thiết kế hướng dữ liệu phải là để cung cấp cho các thuộc tính của thực thể trò chơi như khả năng sinh động, khả năng tương tác, khả năng di chuyển, ... bằng cách sử dụng tính kế thừa. Tất cả phụ thuộc vào một trình quản lý dữ liệu thông minh chỉ cung cấp các thực thể cần thiết cho mỗi thành phần, ví dụ như cho vật lý hoặc hoạt hình.
danijar

@sharethis: Nếu tôi hiểu sự phản đối của bạn, thì đó là đa hình phụ là một tính năng chính của OO. Tôi đồng ý rằng một ngôn ngữ tự xưng là OO mà không có sự hỗ trợ cho nó sẽ là lạ, nhưng điều đó không có nghĩa đó là công cụ đầu tiên cho loại vấn đề mà một người gặp phải trò chơi lập trình, ngay cả khi trò chơi được lập trình theo kiểu OO . Tôi cũng sẽ tranh luận rằng DOD thực sự là về việc tránh các loại đa hình đặc biệt (phân nhóm danh nghĩa) nhưng khuyến khích người khác (trong C ++, đa hình ad hoc với ADL hoặc đa hình cấu trúc thông qua đảm bảo về biểu diễn giá trị).
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.