Class Design for Shops

At the moment lots of our students are working on their first year coursework. This year they can make either a game, which I’ve called “Space Killers” or a management system for a record shop, which I’ve called “Vinyl Destination” (turns out that there actually is a shop with that name – which only goes to show that great minds think alike sometimes). By the way, a record is what very old people used to buy music on. They are pressed out of plastic, usually 7 or 12 inches in diameter, easy to scratch and becoming fashionable again, which is nice.

Anyhoo, one of the central design decisions that has to be made is just how to store information about the records that the shop has in stock. We have been discussing this in the lectures, and it is interesting to reflect how the business needs of the customer affect the organisation of their data. Lots of shops have things to sell, but the way that you would hold their stock information varies from one business to another. I’ve broken these down to three broad categories which I’ve called “Art Gallery”, “Car Showroom” and “Supermarket”.

Art Gallery: In an art gallery each item of stock is unique. Or at least it better had be. Turning up with a second copy of the “Mona Lisa” would probably raise one or two eyebrows. Every item in the gallery has properties such as the artist or artists that made it, the date, the description and the price, but this information would be held for each individual piece in stock. To store the data for this application we would design a class, perhaps called “StockItem”, and then create an instance of this class for each of the pieces that is held in stock.

Car Showroom: This situation is slightly different. The showroom will hold a large number of cars, but they will be of particular models. They will hold a large number of “Ford Fiestas”, but each of them will have different trim levels, colours, ages and prices. If we held the data about our cars in the same way as we hold the data in the art gallery we would store a lot of the same data multiple times. Every individual StockItem would hold its own copy of the name, the manufacturer and lots of other information common to all Ford Fiesta models. A better way to design the system might be to have a class, perhaps called “CarModel”, which holds all the information about the type of car (all the “Ford Fiesta” parts) and then have the “CarModel” class hold a list of all “StockItems”. The StockItem class would hold all the information about a particular car, including things like colour, mileage and price. The CarModel class could hold a list of the StockItems of that particular model. For example, if the garage had a red Ford Fiesta and a blue Ford Fiesta there would be a CarModel object for Ford Fiesta which holds a list containing two items, a StockItem for the red one and a StockItem for the blue one.

Supermarket: In the case of a supermarket which is selling cans of beans, all the cans of beans of a particular type are identical. In this case we don’t need to store information about any individual can, instead we just want to know how many we have in stock. So for the supermarket we just need an object that holds a description of the item and also contains a counter that tells the system how many of that item are in stock.

If you are building a system for a customer, it is worth considering which of the three arrangements makes most sense. In terms of Vinyl Destination I reckon that because the you can get records of different quality it is more like a garage or an art gallery. The shop may have several copies of “Abbey Road” by The Beatles, but some will be in pristine condition (and therefore worth more) than others.