0

I am relatively new to Java - especially when it comes to interfaces and abstract classes (I do know how to use them), however in this case i am a bit confused how i should setup my architecture. First of all, i'd like to say that this is just a project for fun - but ofcourse the main goal is to get experience :-).

Let's get down to business!

I had the wonderful idea of creating a website where you can buy and sell items. I am thinking of using Json, jax-rs and some kind of database(might end with NoSQL/MsSQL.

However, i seem to have a problem of creating the architecture, and how it should be done properly.

All ads have some things in common (They should all contain pictures, ad text, price, etc).. Thats not the problem. The problem is i don't know how to handle all of the differences that some ads might have... Such as an ad under the category "Electronics" might have a lot of different fields than another ad under the category "Clothes"..

I mean.. it could look like this:

Clothes -> Men -> Sweaters

Electronics -> Phones -> Apple

Electronics -> Televisions -> Samsung

How the hell would YOU handle that?

Imagine the two following ads:

AD1: Text: I want to sell my television Price: 100USD TimeCreated: Today(Datetime, whatever) Category: Electronics SubCategory: Televisions ScreenSize: 40" Brand: Samsung Model: 700UHD

AD2: Text: I want to sell my pants Price: 10USD TimeCreated: Today(Datetime, whatever) Category: Clothes SubCategory: Men pants? Brand: Diesel Size: 32 Length: 40¨ Condition: Bad

I really hope you get the idea - im really confused as to how i should handle this issue.

Thanks for your time.

matn
  • 37
  • 7
  • Well, having an *Electronics* tab and *Phones* tab on your website doesn't require you to have classes or interfaces for those, does it? I am not really getting what you want, I think. For differences between abstract classes and interfaces in general, take a look at this: http://stackoverflow.com/a/18778220/5221346 – RaminS Nov 30 '16 at 20:48
  • Hi, thanks for your answer. Im starting it as an android app. When i create a new ad it should ofcourse save it all in a database. My problem is i think its difficult (at least when you dont know the right direction) to handle the different type of ads that can be created.. The amount and type of information about an ad can be completely different depending on which category it is.. – matn Nov 30 '16 at 20:52
  • 1
    You are making this more complicated than it needs to be. If you take a birds view, all products have a lot in common: name, price, age, dimensions, weight. I would simply model them in the most generic way and put the information which are actually used (and which format to present for input) on the category. There is no need for specialized classes to represent products imo. – Durandal Nov 30 '16 at 21:24
  • What do you Mean with "put the information which are actually used (and which format to present for input) on the category"? – matn Nov 30 '16 at 22:10
  • Would you simply create a class with the shared fields (Such as Location, price, age, adText) and then for the rest of the categories create individual classes? – matn Dec 01 '16 at 14:23

2 Answers2

0

Before starting with the architecture of your project you might want to read up on design patterns. What you are describing here:

The problem is i don't know how to handle all of the differences that some ads might have... Such as an ad under the category "Electronics" might have a lot of different fields than another ad under the category "Clothes"..

is a prime candidate for the Decorator pattern.

You can achieve it by both abstract classes or interfaces, but i would give you another powerful tool to consider: Composition

What i would probably do in this scenario is consider implementing single-purpose Interfaces, which are either behaviour or component based. For example, each ad will have a price right? So, i would create an Interface called Priceable and have a class implement it or another Interface extend it. In a way, give your class some behaviour or a component.

There are lots of way to achieve what you are trying to, BUT knowing your design patterns (ya know, tested solutions for common problems, blah blah) is a vital starting point.

Mechkov
  • 4,294
  • 1
  • 17
  • 25
  • Sounds like a ton of interfaces for extremely little functionality? Could you possibly come with a simple example? – matn Dec 01 '16 at 14:17
  • You are welcome to combine common functionality or components, thus making it less obtrusive. It is a tested solution for your problem (design pattern), but you can mold it to your liking. – Mechkov Dec 01 '16 at 14:53
0

Given the range of products can really be huge, I would not suggest to create a new class for each product category or brand as you mentioned in the question. Rather what you can have is just a product class with certain standard attributes, that would contain the brand and product category as attributes. While the brand, product category, and few others can themselves be classes to have additional attributes, there can be other members to cater for other standard fields like product id, name, price, images, etc in the product class itself.

For other non-standard attributes, you can possibly have a map of attribute name to value to make sure the design is extensible for new products that can possibly have new attributes to be modelled, without forcing you to create new classes everytime.

Same on the database front as well: you can have a table for product with the common set of attributes and then extended tables for additional attributes per product category.

I know it doesn't have great details, but hopefully enough high level idea to get you started.

Sourabh
  • 429
  • 1
  • 4
  • 11
  • HI, thanks for your answer. I am not quite sure that i fully understand ur answer. You have some main class with shared attributes(such as text, price, dateCreated, location) - but then what? – matn Dec 01 '16 at 14:19