I've got Item() Class wich stores item id name and description and i have ConsumableItem() with extends Item().

This second item is supoused to be items wich after an use may be deleted from invetory (because the player ran out of them) and obviously they can be used.

So when i want to use a Potion, i add this:

1 2 3

effect = 1; // Where 1 = id of the add hp effect.quantity = 50; // Recuperable amount of the effect.time = 0; // In case of being a buff potion, how much time would it last. 0 is the default value and the program ignores it

The case is, that I'd like to add potions wich has more than 1 effect.

Example: Elixir wich adds 100hp and 100mp

How could i do this? Adding a new effect value would fix it but i dont think thats the best because it would be redundance in the database.

so I assume because you store an effect id(you should use enums btw) you apply the effect later based on this id.why not let the effect know how to affect something.Now when you want to add a new effect you can just create one with new functionality. you can also create a MultipleEffectsWrapperEffectContainerHolder for example which can hold what you requested, one effect to boost hp and one for your mana

This is "food for thought" commentary...not suggesting anyone should change anything...cause whatever works (and is maintainable) is all good.

Someday I should get motivated a write up a description of how I handle game entities. My brain mostly targets very heavy data-driven models, so the first thing I ask myself is "How do these two things differs?" and if the ask can be "the data's different", then I don't add a new abstraction (like extend a class). So from your write-up I'd never have a ConsumableItem() which extends Item() because they only differ by data (where code is data). Also I'm not very keen any the suggested solutions. Why can't a NPC/monster drink the potion? Also I strongly dislike what I consider over-usage of interfaces in Java culture.

Also I strongly dislike what I consider over-usage of interfaces in Java culture.

I guarantee when you work with any non-trivial codebase that you'll find under-use of interfaces to be a worse problem than overuse. Interfaces represent types, classes are implementations of the type. The alternative is subclassing abstract classes, and if you already had another superclass, you're out of luck.

This is exactly the design philosophy that I strongly disagree with. Classes are types. Interfaces are types which specify cross-cuts in a otherwise independent type hierarchy. In my experience troubled projects fall into two rough categories. Those that do little to no advanced design and just start banging out code willy-nilly and those that blindly follow some SW engineer design model as if it were holy writ.

Quote

The alternative is subclassing abstract classes, and if you already had another superclass, you're out of luck.

Dealing with cross-cuts is exact reason why interfaces exist. To flip the coin a set of concrete classes with no-explicit parent class which implement a single interface is pointless. A wash (work wise for the programmer) and more work for the runtime. Take that set and add more interfaces which they all implement, then both the programmer and runtime are losers. To be anal, one isn't always "out of luck" in such situations. There's always the option of composition..not that I'm advocating avoiding using interfaces...that's just as silly as over-usage.

Obviously a class also represents its own interface. The language I used might have implied otherwise, and that wasn't intentional. The point is that people shouldn't think of interfaces as "stripped down classes and you can have more than one", they should think of them as the primary types themselves, with the implementation details kept elsewhere.

Any design philosophy can be taken too far, but I'd rather people erred on the side of being too flexible by using the narrowest interfaces possible, rather than forcing me to subclass and hack around the parts that don't fit.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org