Hacker News Reader

Comment by dynamite-ready | Hacker News Reader

Even here, I feel we're overcomplicating things. For example, possibly ignoring what 'Shoes' are comprised of, were Clothing now to contain:

- Clothing -- Price -- Size -- Colour -- Discount

Then does your scenario really become as big a problem as you suggest? For one, some ontological relationships needn't be described in the same layer, or can simply be implied.

A Red Fox, a Red Ant and a Red Snapper are definitely related in some way, but I wouldn't use the same class to program a representation of all three.

A Red Shirt, and a Red Pair of Trousers/Pants though, probably share enough for a rough outline for online shopping app though.

View on HN

Actually I would not create any Clothing class or abstract thing, but instead probably create a structure, which is named something like "product" and then let it have a flexible attributes container. For example it could have: id, categories, price, product-attributes. Where product-attributes is a key-value thing. categories would be either a hierarchy or tags, but probably tags, as they avoid issues with inventing artificial hierarchies later.

This way I would never need to make a class "shirt" or "pant" or whatever. I would simply add categories for them. Way simpler than encoding this stuff in some class hierarchy. There is that word again, hierarchy. The problem with those is always, that sometimes you will have an item, which fits into 2 sibling categoies or into 2 parts of the tree, which are not on the same path. With classes you will need multi inheritance or you will need to come up with a new parent of both of the classes.

> Where product-attributes is a key-value thing

The problem with this approach (and I've done it) is that product-attributes is now this black hole that's difficult to query, difficult to modify, a huge potential for errors that could even be caused by a typo. It's also incredibly difficult to version.

I regret going with this approach even though it results in far fewer tables and classes. It's short term gain for long term pain. Everything is trade off -- it might well be more than worth it for something not expected to live long or have a lot of changes.

Although I agree with your point that not everything needs to be hierarchy. You can be explicit with your data without having everything inherit from everything else.

Fair point. I guess you would still have to have your conventions (and actually follow them) about what you put in the attributes for which kind of product. I am thinking though, that if you need to implement any new functionality for a specific product, you would discuss it with other developers (or yourself, if you are alone) and find a good convention of what to store and then on another part of the program make use of it. If you wanted to encode the convention into your code, you can create product type specific constructors, which you have to use (another convention!) when creating such a product. Still lighter weight than creating a class for everything and avoids coupling behavior with state.

I guess the approach stands or falls with developer discipline. If you one is not disciplined enough about the conventions and carefully choosing them, one could end up with a mess of a mass of unknown keys in products, which no one knows why or how they got there.

What I'm saying is that trees represent a single path through a graph. As requirements or nodes change, the path can change, or multiple trees can coexist.

Think tags on items represented on a tree, where clicking the tag reorients the category around what you clicked on.

Reply on news.ycombinator.com