The Product class provides a basic class for defining a unit that is moved between Facility agents. This is a class that you are free to extend to include other dimensions that might be of use in your desired simulation (addition of new fields or unique product types, etc)
The Product class is provided and free to extend, the object contains the following fields:
String productID;\ndouble volume;\ndouble weight;\nString trailerID;These are just base features for representing a unit and can be extended to represent more complex or differentiated product / unit types:
\npublic class ElectronicProduct extends Product {\n public String originFacility;\n public String destinationFacility;\n public boolean hazardous;\n}When using a TransportMessage to handle shipment and movement between facilities, it's recommended to use the Product class as the message is specifically designed to carry these objects.
There is another option for representing units and products in the simulation.
\nWhen dealing with large systems with a high volume of products (millions - 100s of millions) under certain circumstances it makes sense to represent the units as a String for memory efficiency. This works quite well in situations where the units are created and do not require manipulation once created (adding to the end of the String can be quite easy and efficient but splicing the String is not).
The TransportMessage class has 3 different constructors for handling both List<String> and List<Product>.
A Product String can use the same fields as the Product class with a unique separator that will be parsed at output.
String uniqueProductID;\ndouble weight;\ndouble volume;\nString origin;\nString destination;\n\nString separator = \":\"\n\nnewProductString = uniqueProductID + separator + weight + separator + volume + separator + origin + separator + destination;This creates the Product String and can be sent using a TransportMessage to ship large amounts of information.