• Post Reply Bookmark Topic Watch Topic
  • New Topic

Class design  RSS feed

 
nick woodward
Ranch Hand
Posts: 382
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm looking to start writing a basic POS system - or for the sake of this question an inventory system I guess - but I'm struggling with the idea of items and item descriptions - which I'm sure you can imagine is a little bit central to the problem!!

Here goes..... (please bare with me!)

Initial thoughts make me think an 'item' object with name/price/description etc is a mistake, because an item description (and other attributes) should exist independantly. I don't want to run out of coca-cola but then lose the coca-cola description or supplier information (for example) because no coca-cola objects currently exist.

So is an ItemDescription object the way to go? Would I 'add' ItemDescription objects to the POS system, and then have generic stock items (SingleItem, CaseOfItem) that have a variable 'ItemDescription'? And then a 'StockList' object could just be an array of those generic items?

Have I got the right end of the stick??? (I'd cross my fingers, but I'm not that hopeful!!) It just seems odd to have an Item object with (as far as I can see) only one field - ItemDescription. I'm sure I'm biting off more than I can chew, but I'm interested in creating something like this and it seems like a good way to learn.

Thanks,

Nick



 
Knute Snortum
Sheriff
Posts: 4287
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The way we did it with the software I was working on is that an item has a QOH (quantity on hand). The QOH might go to zero but this didn't mean the item was deleted. In that case a separate item description is not a necessity.

However, depending on the way the items are described, it might be a good idea to have a description table or have the description partially calculated. For instance, selling a bike where different models vary only be color.

Bottom line is, I think it's fine to have an item with a description field.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An ItemDescription object is NOT the way to go. I can't put my finger on it right now but seems like you're mixing different concerns when you worry about "losing the coca-cola description because no coca-cola objects currently exist".

I have said this in a couple of threads (see http://www.coderanch.com/t/648742/design/Split-Designing-parking-lot and http://www.coderanch.com/t/628047/patterns/Parking-Lot-Design) but starting a design from objects and their attributes often leads to confusion and over-engineering. It's better to start with a clear problem statement and a well-defined context before you start thinking about objects, their responsibilities and attributes, and how objects work together (collaborate) to solve a problem.
 
Paul Clapham
Sheriff
Posts: 22839
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the warehouse system I used to work on, an Item had not only a description, but nearly a hundred other fields. Now I know your system isn't going to be nearly as complex as ours was, (and it's true that our system could have used a bit more database normalization,) but you shouldn't worry about having no fields at all.

By the way our system had two quantity-on-hand fields, one for cases and the other for eaches. We didn't have separate items for case quantities and each quantities, and there was a good reason for that. And as Knute said, the item objects shouldn't ever be deleted until you really really don't need them any more. In our case it was two years after the last time somebody bought the item.

There's lots of ways to design a POS system, and the design can vary depending on whether you're selling bicycles or cigarettes or clothing, so you should probably spend a fair amount of time up front designing your data structures.
 
nick woodward
Ranch Hand
Posts: 382
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
really appreciate the help, thanks. pretty glad i don't have to go down the route i was thinking tbh it was looking like a MASSIVE pain (although to be fair probably because I'm out of my depth!)

when i've something a bit more developed and concrete I'd love some more input if you don't mind - i've only really experienced very small scale and rather disorganised POS and stock systems so feel a little lost when it comes to designing something around/close to best practice.

junilu - that thread looks like it'll help alot, i'll definitely be reading that a good few times, thanks. think you're right on the overengineering part. was stopping me getting anywhere! any books you'd recommend that work through the logic and design of small projects in a similar way?

 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only one I can think of is "Growing Object-Oriented Software Guided by Tests" by Steve Freeman and Nat Pryce. The approach is called Test-Driven Development where you use tests to drive your design thinking. You'll get a feel for the process in the thread where we go through the design of a better parking lot (the one that was [Split] off of the original topic about "Parking Lot Design"). Note that this route is not an easy one -- there are a lot of things you'll need to read up on including Refactoring, automated testing with JUnit, which are not normally beginner's topics. The rewards of learning how to develop programs this way are great though, IMO.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!