Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Item database architecture  (Read 505 times)
0 Members and 1 Guest are viewing this topic.
Offline EliwoodL

Junior Devvie


Medals: 3
Exp: 8 years



« Posted 2018-05-04 06:42:23 »

So, for a little project I'm working on, I've been thinking about an item database architecture.

I have a base class, Item.  I've merely included the code for the fields; the rest of the class is merely getters and setters, and a basic constructor.

1  
2  
3  
4  
5  
6  
7  
8  
// Item name & description.
   private String name, desc;
   
   // Cost per unit.
   private long baseValuePerUnit;
   
   // Size in meters cubed per unit.
   private float sizePerUnitInM3;


That lays the groundwork for commodity-type items just fine - although it'll be fun figuring out actual mathematically-correct values.  A couple examples:

1  
2  
   Item i1 = new Item("Mattress", "A mattress for sleeping on.", 200, 3.5f, false);
   Item i2 = new Item("Iron Ore", "Unrefined iron-bearing ore.", 75, 0.001f, true);


There will be other kinds of items besides basic commodities, however, each with their own sort of information needed:
> Fuel, requires information on energy density, etc.
> Equipment, such as armor plating, shield generators, etc.
   > Each kind of equipment would require its own unique set of data
      > Armor plating: thermal rating, kinetic rating, etc.
      > Shield generator: thermal rating, kinetic rating, etc.

Now, I'm not a fan of inheritance.  I would really like to avoid it.

To that end, I wanted to ask the folks of JGO, what's your take?

My first idea was to put one of these in there:

1  
   private HashMap<String, Object> addedFields;


and then create a bunch of helper methods.

The other idea I had is to design a sort of super light-weight component system for the items, and then construct unique items via composition.

If you know of any design architectures that could work here, I'd love to hear.  This is less of a question on "Hey, how do I do this exactly" and more of "Hey, what's your thoughts and own experience on this sort of thing."  Links to working examples of open source code are also most welcome!
Offline ByerN
« Reply #1 - Posted 2018-05-04 09:08:03 »

Quote
My first idea was to put one of these in there:
1  
private HashMap<String, Object> addedFields;


This is the first thing that comes to mind when you are thinking about solving this kind of problem.
In my opinion- don't do this! Generic solutions like this are making everything harder. It's easier to get lost in it. You are losing advantages of your programming language because you change your code into one big hashmap of hashmaps!

Quote
The other idea I had is to design a sort of super light-weight component system for the items, and then construct unique items via composition.

Yeah-
If you don't like inheritance- use it's alternative- composition based on interfaces. SOLID and design patterns would be helpful.

What I am doing in this kind of problem:
-listing items
-describing what can be done with these items, when, how etc (behaviour)
-describing interfaces that are covering the behaviour :
some objects can be destroyed - implements Destructable
some objects are doing something on step - implements Steppable and OnStepListener
some objects are for example potions that you can drink and it's adding you some attrs but I don't want to repeat everything for each type- Base class - GenericPotion implements Drinkable and got some hooks for describing specific data (template pattern for example. Or strategy design pattern) so you can just fill your GenericPotion template and get HP potion or MP potion.

If you have some more questions. Ask me Smiley I hope it helped.

PS.
I was working on multiple commercial projects where one of the main principle was making everything flexible (runtime) as much as possible.
There are my thoughs:

<---------------------------------------->
non-generic                             generic

-non-generic: Less flexibility, less complexity - harder to add new functionality, easier to maintain
-generic: More flexibility, more complexity - easier to add new functionality, harder to maintain

harder to maintain = easier to fail
too hard to maintain = fail

Now when somebody asks me to do "flexible-generic-all-in-one tool" I say "yeah ok, I will just prepare classloader for you and you'll put your java classes implementing my interfaces".
They say: "but wait, I am not a programmer. I don't know how to create a class in Java. I want just put some values in the excel and make everything work"

If you accept it- your project will take years and fail so hard at the end Smiley
Pages: [1]
  ignore  |  Print  
 
 

 
DesertCoockie (33 views)
2018-05-13 18:23:11

nelsongames (75 views)
2018-04-24 18:15:36

nelsongames (70 views)
2018-04-24 18:14:32

ivj94 (752 views)
2018-03-24 14:47:39

ivj94 (82 views)
2018-03-24 14:46:31

ivj94 (622 views)
2018-03-24 14:43:53

Solater (98 views)
2018-03-17 05:04:08

nelsongames (179 views)
2018-03-05 17:56:34

Gornova (405 views)
2018-03-02 22:15:33

buddyBro (1065 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!