Làm thế nào tôi có thể xử lý hàng tồn kho theo cách hướng đối tượng?

Tôi đang cố gắng nghĩ ra cách tốt nhất để xử lý hàng tồn kho của người chơi theo cách tiếp cận hướng đối tượng.

Ví dụ, kiếm và rìu là hai lớp khác nhau, cả hai đều thừa hưởng từ vũ khí. Vũ khí và thuốc cũng là những lớp khác nhau cả hai kế thừa từ vật phẩm.

Lý tưởng nhất là hàng tồn kho sẽ được triển khai như một thùng chứa các mặt hàng, nhưng điều đó không thể được thực hiện vì nhiều lý do. Vì vậy, nó phải là một thùng chứa các con trỏ vật phẩm (thông minh). Vì tôi không muốn đọc mã của mình bằng các lệnh gọi mới và xóa, tôi sẽ bọc nó trong một lớp ItemWrapper có tin tức / xóa trên ctor / dtor.

Vì vậy, mã sẽ trông giống như thế này

class Sword;
class ItemWrapper;

//Prepare the long sword.
const Sword longSword(...params...);

//Declare the inv
vector<ItemWrapper> inv;

 //Add it to inventory
inv.push_back(longSword);  //compiles if ItemWraper(const Sword&) is defined.

Cách tiếp cận này là cách tốt nhất tôi có thể đưa ra về mặt rõ ràng của mã và dễ viết. Vấn đề là ItemWrapper sẽ cần một hàm tạo cho mỗi lớp lá kế thừa từ Item (rất nhiều).

Đây là nỗ lực đầu tiên của tôi ở đây, vì vậy tôi muốn biết: tôi có đi đúng hướng không? hoặc nếu có một cách tốt hơn để làm điều đó (có lẽ là một cách tránh rất nhiều nhà xây dựng)?

Có một cái gì đó bạn đang làm ngay bây giờ mà bạn có thể thấy rằng bạn hối hận về sau, mặc dù nó có vẻ như là một điều hợp lý để làm.

Bạn có thể thấy rằng làm cho mỗi loại mặt hàng trở nên khó quản lý khi bạn có hơn mười hai trong số chúng.

Hệ thống quản lý hàng tồn kho của riêng tôi không có các loại khác nhau cho các mặt hàng. Thay vào đó, tôi sử dụng lớp "Mô tả", có một tập các thuộc tính (cặp Tên-Giá trị, được lưu trữ trong một thùng chứa kết hợp [trong C ++, bạn có thể sẽ sử dụng std :: map])

Trình lấy thuộc tính là một hàm mẫu để biến thuộc tính từ bản đồ thành loại thích hợp.

Cách tôi phân biệt giữa các loại vật phẩm là có thuộc tính ItemType, thường là một loại enum với các mục như WEAPON, ARMOR, v.v. Các thuộc tính khác chứa phạm vi thiệt hại, tham chiếu đến hình ảnh để sử dụng để hiển thị nó, mô tả tên, v.v.

Bây giờ, những mô tả này không dành cho các trường hợp mục. Họ mô tả các loại mặt hàng nói chung. Các thể hiện của vật phẩm chứa một số loại tham chiếu đến bộ mô tả cũng như một bản đồ các thuộc tính tương tự cho các giá trị cần thiết cho một thể hiện vật phẩm (ví dụ như độ bền riêng lẻ). Theo cách này, người ta tránh lặp đi lặp lại cùng một thông tin. Rốt cuộc, một thanh kiếm cũng giống như một thanh kiếm khác, nó có thể gần như bị hao mòn hơn.

Để tránh các cuộc gọi của nhà xây dựng, tôi khuyên bạn nên sử dụng một phương thức xuất xưởng.

Ví dụ, kiếm và rìu là hai lớp khác nhau, cả hai đều thừa hưởng từ vũ khí. Vũ khí và thuốc cũng là những lớp khác nhau cả hai kế thừa từ vật phẩm.

Tôi sẽ không làm mọi thứ theo cách này; một thanh kiếm và rìu khác nhau chủ yếu trong dữ liệu của họ, không phải là hành vi cơ bản của họ như vũ khí. Tương tự như vậy với các mặt hàng. Tôi sẽ tránh việc lạm dụng quyền thừa kế này, bắt đầu bằng cách giới hạn bản thân mình Weaponvà Item(bạn thậm chí có thể xếp chúng vào một lớp duy nhất, nhưng đó là một cuộc thảo luận khác). Nếu không có gì khác, điều này sẽ làm giảm bớt vụ nổ của nhà xây dựng mà bạn đang thấy ItemWrapper.

Vì vậy, nó phải là một thùng chứa các con trỏ vật phẩm (thông minh). Vì tôi không muốn đọc mã của mình bằng các lệnh gọi mới và xóa, tôi sẽ bọc nó trong một lớp ItemWrapper có tin tức / xóa trên ctor / dtor.

Hãy xem xét Boost con trỏ thông minh thay vì tự lăn. Chúng khá tách biệt với phần còn lại của Boost (vì vậy bạn không có quá nhiều sự phụ thuộc để tham gia nếu vì lý do nào đó, bạn không muốn tận dụng phần còn lại của công cụ gọn gàng của Boost) và nhiều chúng đã được chấp nhận là một phần của thư viện tiêu chuẩn mới trong C ++ 11, vì vậy bạn không nên gặp vấn đề nâng cấp.

Đây là nỗ lực đầu tiên của tôi ở đây, vì vậy tôi muốn biết: tôi có đi đúng hướng không? hoặc nếu có một cách tốt hơn để làm điều đó (có lẽ là một cách tránh rất nhiều nhà xây dựng)?

Như trên, tôi sẽ cố gắng tránh kế thừa cho việc này và xem xét sử dụng các giải pháp của bên thứ ba đã được thiết lập thay vì tự mình thực hiện. Những bước đó một mình sẽ loại bỏ phần lớn sự phức tạp bảo trì mà bạn đang khám phá (hoặc sẽ sớm khám phá).

Điều đó nói rằng, một cách tiếp cận khác là xem xét nó theo cách này: ItemWrapperlà một hỗ trợ ban nhạc cho một vấn đề chi tiết thực hiện. Bản thân nó không đại diện cho một "đối tượng" thực sự theo bất kỳ ý nghĩa điển hình nào. Vì vậy, hãy suy nghĩ về những gì có thể là một sự tương tự tốt hơn cũng giải quyết vấn đề của bạn là có một nơi để đặt tự động newvà deletecác cuộc gọi.

Hầu hết hàng tồn kho cho phép (một số) vật phẩm xếp chồng lên nhau, phải không?

"Khả năng xếp chồng" của một vật phẩm là một thuộc tính của vật phẩm đó, nhưng bản thân vật phẩm đó không chịu trách nhiệm duy trì ngăn xếp. Nếu bạn có một lớp đại diện cho một ItemStackphương thức để truy vấn kích thước của ngăn xếp, tách ngăn xếp, et cetera thì bạn có thể đặt quyền quản lý vòng đời của con trỏ vật phẩm (mà tôi cần lưu ý, có thể trở nên phức tạp hơn một chút với các ngăn xếp , do đó cung cấp một đối số khác để sử dụng một cái gì đó như Boost) trong lớp stack cùng với việc thực hiện phần còn lại của hành vi của nó. Các mục không thể xếp chồng được thể hiện bằng một ngăn xếp luôn chứa một mục duy nhất và bản thân kho lưu trữ của bạn vẫn xử lý các trường hợp đồng nhất của ItemStack.