Displaying A Long List of ObjectsSource: firstname.lastname@example.org
Problem: How can you efficiently provide a long list of objects for display?
[...] the system should provide a list of stock items to the user. [...] we used a 'collection class' named StockList which can store the list of all stock items. StockItem itself is a class with many attributes.
[...] will the StockList class instantiate all the instances of stock item class (which may be in tens of thousands), add all instances to it and then provide the list to the user? [...] will it not affect performance?
Or maybe the collection class need not instantiate all the instances of StockItem class to provide the list? If so how it is implemented?
H. S. Lahman replied:
The problem with short descriptions is that one has to make assumptions about the problem space. I assume that
[There are variations on this theme, depending upon the assumptions. For example, StockListRequest might exist always while a FilterCriteria object was created/deleted around each user request. The FilterCriteria would have the responsibility of deleting the old relationship and creating a new relationship between StockListRequest and StockItems for the current request. Which is the best approach can be a very close call and depend on rather subtle issues in the problem space.]
You certainly don't want to instantiate a bunch of copies of StockItems for the particular collection -- the computer will be obsolete by the time the application finishes. B-) The real output is just a list of data extracted from stock items, so you really don't need objects for this -- at least not in the low level implementation. You can extract the data by 'walking' the instantiated relationship between StockListRequest and the StockItems and streaming the data to the user interface as you go. This would be a responsibility of StockListRequest.
In my solution you need an efficient method for StockListRequest to apply the user's filter to select the relevant stock items. For tens of thousands of instances this will probably require the existence of at least one sorted index of StockItem instances that might be a separate object or embedded as part of the static implementation of StockItem. A separate index would be appropriate if the filters are complex or the criteria are not relevant to the StockItem abstraction. The embedded index might work if the filter criteria is limited and inherent in the StockItem abstraction. In either case, it has to be updated by the ctor/dtor for StockItem as stock items are added and deleted.
You will also need an efficient instantiation of the relationship so that once you know which StockItems are related you can 'walk' them efficiently to produce the output list. This is probably just a dynamically allocated array of pointers to StockItems in StockListRequest's private implementation, but it could be a separate object if you are into reuse.
The specific things you do for performance will depend upon the
language and other aspects of the computing platform -- what I
described above is just one way of dealing with performance. [...] a
key issue is that much of the software structure (e.g., index objects,
etc.) [...] is not relevant to the solution until you are dealing with
rather low level implementation issues. The key ideas for the