Displaying A Long List of Objects

Related Sites

[...] 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?

The problem with short descriptions is that one has to make assumptions about the problem space. I assume that

1. the user provides a request for a unique set of stock items each time;
2. that objects, say StockItem, already exist somewhere in the application to describe the items you have in stock;
3. the user just wants the stock items identified (e.g., a list of part numbers) and some subset of data (e.g., price) concerning the stock item; and
4. the user provides some filter criteria that defines the set of stock items requested (e.g., all items whose part identifier starts with 'K').

[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 OO model are simply:

• an object abstracting the request -- StockListRequest.
• a relationship from it to relevant existing stock items -- StockItem.
• request has the responsibility of instantiating the relationship to specific stock items based upon request criteria (mechanics are performance sensitive).
• request has the responsibility of navigating the relationship to extract the relevant stock item information (mechanics are performance sensitive).
• request has the responsibility of returning the extracted stock item information to the user -- a data flow that depends upon UI.
• request and its relationship to stock items exist temporally only while the user request is active.

ootips, Transferring a Large Number of Objects From Server to Client