So basically you want to know how to structure your Item class/es for game development. Well now that you mention Diablo II, you might look further into how they did it. There's been a lot of progress into reverse engineering D2, and you can get an inside look into the memory, stack, hex, asm, packets, etc. If you load up a trainer you can get an idea of how they laid it out. I don't think they subclassed, but rather just had a property for the item type. They also had properties for the item requirement, item drop level, item quality (set, unique, etc), item durability, list of attributes,. The reason using a property over inheritance could be because it's an old game and OOP wasn't a major factor, or because when you store the list of items in a database you use a field, and that is easier to convert into a property than using a switch to determine the subclass.
It's easier to design the code after you setup a database. You want to be able to add/remove items, item types, item qualities, etc. on the fly. So lets say you have a SQL table for items, a table for effects, a table for item types, a table for item qualities (which in turn have fields for other attributes). The point here is just setup your code as a clone of how your database is setup. Hopefully in a generic, relational, way.
You can do this for everything, and it works out to perfectly map every different attribute about the game. To the point you can change the graphics and the database attributes so you have an entirely new game. Think of it like a tree of game settings, with branches of branches of different aspects about the game. All you do is parse the database, just as you would parse a graphics model (wrapper).
quality = new ItemQuality(... sql here ...)
type = new ItemType(... sql here ...)
// callbacks whatever - can load and parse script files here, eg. /effects/9357334.ie
I use IDs, D2 uses "item codes" which are like EGB, JUV, BPO and such.
field type_id // this links to the record down below
field quality_id // so does this
table game_item_attribute_list //this is how you replace parsing a comma delimited string into an array
field type_id // right here
field quality_id // and here
insert into game_item_type_icons set icon_id = 3, icon_filename = "twohandedsword18943.jpg"
insert into game_item_types set type_id = 2, type_title = "Two-Handed Sword", type_icon = 3
insert into game_item_qualities set quality_id = 1, quality_title = "Unique", quality_color = "F0F0F0"
insert into game_items set item_id = 5, item_title = "Backlash Fist", type_id = 2, quality_id = 1,
item_level = 51, item_required_level = 45, item_quantity = 1
// grab an item from the database
$item = select * from game_items where item_id = 5
left join game_item_types on game_items.type_id = game_item_types.type_id
left join game_item_qualities on game_items.quality_id = game_item_qualities.quality_id
// grab the item effects
$effects = select * from game_item_attribute_list where item_id = $item['item_id']
// should also find a way to grab the item icon
// these can all be merged into ONE database query
When it comes to relational databases you can parse a string into a list, or you can use an entirely new table which acts like a huge multidimensional array (just choose the element with the correct item id).
If you look into World of Warcraft or any other MMORPG private servers you will get a good idea for what I'm talking about, how to setup an item database, and how to parse the database into your game.
Note you don't have to use SQL, you could use a flat-file database (custom), or hardcoded arrays. It makes no difference.
If you were using a scripting language, or building objects generically, you wouldn't even have to design more than one class - Item.