Need some tips... Sharing a collection of classes for display in a listbox?
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
Hi, I see no fundamental difference between displaying vehicular text in a TextBox and the same in a ListBox. You never have to use binding, but you can. Without using any binding, you can iterate your Dictionary and build a string for each Vehicle (I'd say your Vehicle.ToString method should serve that purpose), then add that string to the ListBox.Items Or indeed you can set up a List of Vehicles and use binding; I know I wouldn't, as I don't like creating a second collection with all the risks of getting out of sync... You could consider using Dictionary.Values as the list of items to be displayed; depends on how you handle empty spots I guess. :) PS: the one advantage of using a ListBox, if your app would need that, is that you can actually paint some graphics in a ListBox item (an icon, a picture, whatever); a ListBox collects objects, they don't have to be strings! It would require you to add the actual Vehicles to the ListBox.Items, your ListBox to be set to UserDrawn mode, and you to implement a DrawItem handler. PS2: can you store a couple of bikes in one spot?
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
Personally I would use a List and binding, but then I use WPF not winforms. I find List<> to much more maintainable and manageable. I would also not allow database/binding or list/dictionary efficiency to influence my decision with such a small number if items.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Hi, I see no fundamental difference between displaying vehicular text in a TextBox and the same in a ListBox. You never have to use binding, but you can. Without using any binding, you can iterate your Dictionary and build a string for each Vehicle (I'd say your Vehicle.ToString method should serve that purpose), then add that string to the ListBox.Items Or indeed you can set up a List of Vehicles and use binding; I know I wouldn't, as I don't like creating a second collection with all the risks of getting out of sync... You could consider using Dictionary.Values as the list of items to be displayed; depends on how you handle empty spots I guess. :) PS: the one advantage of using a ListBox, if your app would need that, is that you can actually paint some graphics in a ListBox item (an icon, a picture, whatever); a ListBox collects objects, they don't have to be strings! It would require you to add the actual Vehicles to the ListBox.Items, your ListBox to be set to UserDrawn mode, and you to implement a DrawItem handler. PS2: can you store a couple of bikes in one spot?
Luc Pattyn [My Articles] Nil Volentibus Arduum
Thanks Luc. Yes, I could just iterate through the dictionary and populate the listbox but my concern is that I would be exposing the 'master' collection to the form. From an abstraction point of view I was trying to avoid this and only allowing a method (parkinglot.displayitems) to output the contents of the dictionary in a read only form (currently a string that is formatted ready to just display in the textbox)... this is where I've now got confused! Do I just return a copy of the dictionary from this method or some other collection (which I can then iterate through or bind to), or do I just expose the master dictionary object? I'm trying to follow/show good design practices with this project :-/
-
Thanks Luc. Yes, I could just iterate through the dictionary and populate the listbox but my concern is that I would be exposing the 'master' collection to the form. From an abstraction point of view I was trying to avoid this and only allowing a method (parkinglot.displayitems) to output the contents of the dictionary in a read only form (currently a string that is formatted ready to just display in the textbox)... this is where I've now got confused! Do I just return a copy of the dictionary from this method or some other collection (which I can then iterate through or bind to), or do I just expose the master dictionary object? I'm trying to follow/show good design practices with this project :-/
When you return a collection of objects basically it is an array of pointers. Making the collection read-only protects the array, not its elements (the objects it refers to). So whatever you do, as long as you export instances of Vehicle, they become public and modifiable. There are two ways to remedy this: 1. Create and export a deep copy: build a new collection with copies of your Vehicles. Now if Vehicle contains references (say to a Manufacturer class), then these objects must be deep copied too. That soon gets very cumbersome. 2. Create and export exactly the information you need, in a data structure that isn't otherwise used in your ParkingLot class. In this case that would be a list of strings. And then you should create this data each time it is requested, you should not store it inside ParkingLot and just pass a pointer, as then one client could still falsify the information another client gets. Either way, the clean approach is to provide a ParkingLot property or method that creates and returns the information required; and then you can use that any way you want, no harm can be done to the ParkingLot. The one thing you probably would also need is a way to signal the outside world your ParkingLot has changed. An event seems appropriate here. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
When you return a collection of objects basically it is an array of pointers. Making the collection read-only protects the array, not its elements (the objects it refers to). So whatever you do, as long as you export instances of Vehicle, they become public and modifiable. There are two ways to remedy this: 1. Create and export a deep copy: build a new collection with copies of your Vehicles. Now if Vehicle contains references (say to a Manufacturer class), then these objects must be deep copied too. That soon gets very cumbersome. 2. Create and export exactly the information you need, in a data structure that isn't otherwise used in your ParkingLot class. In this case that would be a list of strings. And then you should create this data each time it is requested, you should not store it inside ParkingLot and just pass a pointer, as then one client could still falsify the information another client gets. Either way, the clean approach is to provide a ParkingLot property or method that creates and returns the information required; and then you can use that any way you want, no harm can be done to the ParkingLot. The one thing you probably would also need is a way to signal the outside world your ParkingLot has changed. An event seems appropriate here. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
Ah, yes, of course they are. Completely forgot it just stores pointers to the objects. Thanks for pointing that out!! As I said, it's been a while! Thanks for your help :-)
-
Ah, yes, of course they are. Completely forgot it just stores pointers to the objects. Thanks for pointing that out!! As I said, it's been a while! Thanks for your help :-)
You're welcome. :)
Luc Pattyn [My Articles] Nil Volentibus Arduum
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
Performance is not an issue, even with thousands of dictionary entries. Your "parking lot" class is in effect your "data repository", and you can use a similar pattern for that. Ultimately, your "backing store" may be be XML or a data base; if a "client" needs a "list", they get a list; if they want to "empty" a parking spot, there's a method for that, etc. The client doesn't care what the backing store looks like, it just wants what it needs. And as Luc pointed out, it's all references to existing objects unless you're cloning.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
I would suggest you model a "parking lot business:"
PLotBusiness
Finances ? PLotData : map vehicles to locations, status, etc. VehicleManager Cars Vans PLotManager SpacesI would use methods in these classes that returned collections, or datatables, for binding to Controls as necessary. imho, the separation of concerns in this model is desirable. "Let the atoms remain ignorant of how they are used in molecules," I once said :) for UI design, think about the end-user: their technical depth, their role, their needs, security ...
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
-
Ok, very basic to you guys but I'm hoping someone can offer some advice. I'm making a parking lot windows forms project and have a class structure of: Vehicle Car:Vehicle Van:Vehicle etc. Then a ParkingLot class which declares a private Dictionary collection of type to store all the instances. The key is a parking space code e.g. A1, A2, B1, B2 etc, which then returns the vehicle object associated with that slot in the parking lot. I've made the dictionary private so that all of the functionality is contained in the parkinglot class and the form button presses etc only update the dictionary via public methods in that class for abstraction/separation of concerns (if that's the correct terminology!). The contents of the dictionary are currently displayed in a textbox by calling a parkinglot.displayinventory method which loops through the dictionary items and uses a stringbuilder to create and return the details of all the items to display in the textbox. All was fine, however, now I want to change it to display the contents in a listbox rather than a text box and now I'm questioning whether using a dictionary object was a good idea (I was thinking of the efficiency of retrieval O(1) of dictionary vs O(n) of list and all that). Should I just use a public List which I can then bind to the listbox? But then I thought from an abstraction point of view, having the list of items accessible from the form/view was a bad thing?? Should I stick with a private dictionary for efficient retrieval and create and return a readonlycollection object from the displayinventory method for binding (or something similar)? It's been a while since I've worked with collections and classes and things like this and I've confused myself no end with something so simple! Any tips much appreciated :-)
Expose a Cars property:
public IEnumerable Cars { get { return _dictionary.Values; } }
// can be shorted to
// public IEnumerable Cars => _dictionary.Values;
// if you like being modern.(This assumes:
private Dictionary _dictionary;
) Bind parkingLot.Cars to your listbox. Make sure Vehicle has a ToString() which renders it as you want it to appear in the listbox.
Truth, James