Passing IDs instead of entire objects is not an Object-Oriented approach
manoelcampos opened this issue · comments
IMPROVEMENT
The tool is a discrete event simulator that relies on message passing to execute simulation tasks.
However, several times it is passed raw data types into messages that are not type safe and makes
difficult to know what exactly a given method parameter has to receive.
Detailed information about how the feature should work
The SimEntity.send method, which is used by several sub-classes, receives an Object data parameter, that usually is an array of entities' IDs. The DatacenterSimple.processVmCreate method is an example of this problem, where the parameter is filled with the Datacenter ID, the VM id and a last integer to represent a boolean value.
Considering that the method send is used to pass several and totally different kind of data for different entities, it should be tried to pass a specific object with everything that is needed, instead of an int array. This object shouldn't just store these IDs into different attributes, but instead, store the objects that these IDs represent.
The problem of using IDs to create relationships happens in other contexts, such as to relate a Cloudlet to the Vm that will run it and the broker that represents the Cloudlet customer, it is used a set of IDs, respectively, vmId and brokerId, instead of a Vm and DatacenterBroker attributes.
The use of these IDs also requires Integers instead of entire objects when passing messages during simulation execution.
Some attributes that have to be changed from int to a specific object (the default value has to be set using the NULL object pattern)
- Cloudlet.userId, Cloudlet.vmId
- Vm.userId
- VmScheduler and CloudletScheduler internal attributes
- Objects of type List or Map where the key is an Integer representing the ID of some object instead of the object itself.
- Several classes inside the network package, including all the NetworkPacket implementations.
A brief explanation of why you think this feature is useful
The proposal improves the OO design, makes the code type-safe and clear to understand and tries to avoid runtime cast exceptions.
Passing an entire object doesn't increase memory footprint once it is passed just a reference to an already instantiated object.
After all, creating true OO relationships using objects instead of IDs, allows you to navigate through the entities to get the data that you want. For instance, to know what is the Datacenter where a cloudlet is running would be possible just by calling cloudlet.getVm().getHost().getDatacenter().
This is true OO relationships and will allow developers using the simulator to get a lot of information about the execution of their simulations in an intuitive way.
This improvement has been made along the time. The commit 954e32e also fixed the issue for Cloudlet, Vm, Host and Datacenter classes, allowing a chained call such as cloudlet.getVm().getHost().getDatacenter().