Timeline for Information Spilling Across Object Boundaries
Current License: CC BY-SA 2.5
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 6, 2011 at 1:15 | comment | added | Winston Ewert | In my case getting the inventory object from the id is handled automatically by the orm. I attempt to access the inventory attribute which causes the system to look at my inventory_id and load the correct record. If I didn't have that then passing inventory_ids to an Inventory object like that would make sense. | |
| Jan 5, 2011 at 14:35 | comment | added | Pemdas | If I changed the function Inventory.ItemsLefts(int itemID) to take an Item object then I don't believe that it really encapsulates anything because I would have to populate the object just to make the function call. I would still have to know what "type" the inventory id is. | |
| Jan 5, 2011 at 14:33 | comment | added | Pemdas | This format (InventoryItem, Customer, int) is exactly what i suggested for the GetPrice function. The other function I put out there are primarily DB management functions. For example restocking an item Inventory.AddItem(int itemID, int quantity) | |
| Jan 5, 2011 at 6:25 | comment | added | Winston Ewert | Now, I could have all that without using objects and instead passing around InventoryItemIds. I may be able to do such a thing in some languages simply by using a typedef. The problem is that I don't see a good reason to have both InventoryItemIds and InventoryItems floating around in the code. There is really only one concept of InventoryItem in my head which will cause me to confuse the two versions in my code. So thus, why have anything besides just the InventoryItem class? | |
| Jan 5, 2011 at 6:22 | comment | added | Winston Ewert | I don't want to pass ints around. I want my types to indicate what kind of object I'm dealing with. Why? Firstly, this gives me type checking. I can tell when I pass the wrong id to my function: I'll get an error. Secondly, the fact that my primary keys are ints is a implementation detail. I'd prefer that to be encapsulated. (I've actually had a couple of cases where I had to change the types of my primary keys). Thirdly, when I say that function takes the arguments (InventoryItem, Customer, int) that gives me a much better idea of what is going on then saying it takes (int, int, int) | |
| Jan 4, 2011 at 23:46 | comment | added | Pemdas | Why...other than the fact that an id is not an object. What is your justification? | |
| Jan 4, 2011 at 23:44 | comment | added | Winston Ewert | @Pemdas, yes, there will have to be ids. But in my code I prefer to not deal with them. I'd rather pass an InventoryItem object (which would contain the id) to the PriceRules object then passing the item id. | |
| Jan 4, 2011 at 23:39 | comment | added | Winston Ewert | @Pemdas, the pricing schemes being considered are too complex to be being stored in an Inventory table and thus InventoryItem objects. So you have a valid point in that the InventoryItem objects would not contain the necessary information to determine the price. Instead we probably have something like a PriceRules table. You are suggesting that Order collects all relevant information and passes it off to the PriceRules object (or equivalent) and thus obtains all the prices. | |
| Jan 4, 2011 at 2:40 | comment | added | Pemdas | I am not really sure what you are asking in the second comment. Not everything has to be an object. I am really not sure how you would locate a specific item without some sort of id. | |
| Jan 4, 2011 at 2:36 | comment | added | Pemdas | I am not really suggesting that at all. I think that you should still have a class or structure for order items. I just don't think that the individual inventory item objects should have the price inside mainly because I am not sure how you would get it in there with out asking some sort of database. The order or inventory item would strictly be a data class containing a item identifier and a quantity. The order itself would have a list of these objects. | |
| Jan 3, 2011 at 23:05 | comment | added | Winston Ewert | What doesn't make sense to me is why you'd want to have Inventory be referenced using id numbers rather then object references. It seems way better to me to keep track of object references and quantities then item ids and references. | |
| Jan 3, 2011 at 23:04 | comment | added | Winston Ewert | Essentially, your idea would be to eliminate OrderItem instead Order keeps track of all that information itself. It is then easy to pass that information off to another object for pricing information. That could work. (In the particular scenarion this example is loosely based on the OrderItem was too complicated and really did need to be its own object) | |
| Jan 3, 2011 at 20:40 | history | edited | Pemdas | CC BY-SA 2.5 |
Edit suggestion based on comment ; added 30 characters in body
|
| Jan 3, 2011 at 19:33 | comment | added | Winston Ewert | Its perfectly fine to ask for data from closely related classes. The problem arises when I'm accessing data from indirectly related classes. To implement that logic in the Order class would require the Order class to be deal directly with the Inventory object (which contains the necessary pricing data). That's the part that bothers me because it is coupling Order to classes which (ideally) it would know nothing about. | |
| Jan 3, 2011 at 17:44 | history | answered | Pemdas | CC BY-SA 2.5 |