This program is going to make use of a number of containers within containers. For example, there will be a Bowler class which has sub elements or attributes with values such as name, address, etc. There will also be a container full of many bowlers, and there may be a need for another container to hold many other containers such as Bowlers, Teams, Awards, etc. This latter container might end up being the Mediator, so I’m not concerned with it here. * = Existing Java class or interface
The container of Bowlers or Teams, for example, would be from this first group.
| Accessor | Bag | Basic | Basket | Box* |
| Bucket | Bundle | Category | Chooser | Container* |
| Control* | Data* | DataSource* | DataStore | Delegate* |
| Element* | Emitter | Entity* | Exchanger* | Group* |
| Handler* | Helper | Holder* | Host | Info |
| List* | Locator* | Locker | Manager | Navigator |
| Pail | Pile | Pool | Pot | Principal* |
| Provider* | Queue* | Reference* | Repository | Resolver* |
| Retainer | Sack | Sequence* | Service* | Stack* |
| Storage | Store | Support | Tracker | Tree* |
| Trunk | View* | Warehouse |
Next is the element of the above container, a Bowler, Team, etc. This is also a container of various attributes with values so something from the above group may also be appropriate. Java considers an item in a collection to be an "element", of which Java has one class and several interfaces named Element. Using that term for a specific class in my program would be very confusing. Here are some additional possibilities:
| Block | Component* | Element* | Item |
| Option* | Record | Row |
Next are the attributes or values held in the above container. This would be things like name, birthdate, number of teams, or a list of bowlers. Notice that these values can be any of many different classes, such as String, Date, List, Integer, among many other possibilities, including classes I create within the SBS program. Here are some possibilities for this class:
| Attribute* | Basic | Cell | Characteristic | Column |
| Component* | Content | Descriptor* | Entity* | Field* |
| Item | Kind | Line* | Simple | Node* |
| Part | Setting | Slot | Thing | Type* |
| Unit | Value | Variable |
Besides having separate names for each of these containers and values, I considered having them related to each other as actual objects are related to one another. Starting with the larger container and working down to a smaller single element or value, here are some examples I thought of:
| Database Table Record Field* |
Book* Sheet Row Cell/Column |
Body Table Row Cell/Column |
Data* List* Entity* Cell |
List* DLL DLLItem Cell |
| List* Lists Container* Cell |
Collection* Document* Page Paragraph |
Top Middle Lower Bottom/End |
Huge Large Medium Small |
DWord Word Byte Bit |
| Tree* Trunk Branch Leaf |
Unit Assembly Component* Part |
Book* Chapter Page Word/Line |
Cabinet Drawer Folder Sheet/Page |
ArrayList* LinkedList* Element* Cell |
| Class* Method* Block Variable |
Universe Galaxy Solar Planet |
Make Model Option* Color* |
Paragraph Line Word Letter |
My decision on what to use takes into consideration a desire not to have class names which will be similar to Java classes. If they were similar it would cause confusion when I’m coding and for anyone else who might like to work on this program. Thus using a class containing the word List would make the observer think it was based on the Java Collection item List, which it may not be related to.
At the lowest level, I liked the word characteristic, but it is too long to keep writing out. So, in the tradition of internationalization, which is shortened to I18N (18 letters are between the first I and last N) and localization (L10N) I considered C12C. While that could probably do, I instead chose to use "tic", being the last three letters. My class is, therefore Tic. A Tic will contain a value which might be any other class object.
Moving up to the next level, which is an item which contains Tics, and which will itself become an element in a collection, I chose the name Record. I was surprized that Java didn’t already have a class by that name. Thus a Bowler will be a subclass of Record.
I first considered naming the class which will be a collection of Records as RecordCollection. This would be useful since it describes the elements in the collection, and doesn’t imply a certain kind of backing store, such as List (RecordList), Set, or Map. Collection is a long word, so I’ve decided to use Store as the name. Actually, RecordStore. Now that may remind us older folks of the days when that refered to a store which sold records (vinyl!), but those are obsolete, so I’m going to use that term.