Wednesday, August 26, 2009

How to transform a java object, a dto essentially, in a "shape" of the information it keeps

An object of the type I'm taking into consideration has few things to offer to be manipulated (and this is good): it has "getters" and "setters" methods, plus values kept is class variables accessed by these. Now, what do I mean for shape of an object ? I speak with myself but it is anyway a good question. Shape is the object represantion that can be viewed by an agent that must be able to do operations on these. I'm speaking about a composable information unit produced from a dto of data received by sensors. So, shape has not to change with time passing, and many read operations on the same object must find the same "shape". The conclusion of this analysis is that the shape of a dto is a sorted list of key-value pairs with its getters and setters methods names as key, and values retrieved by the calls to these as... values.

Example: object class "person"

key: value:
getName stefano
getAge 35

This seems to run fine until I don't get into considerations the writable methods: the setters.

Information rendering: from sensors' readings to composable information units

Code on svn repository is at a very interesting point: I need now to define how to render a DTO java object (the paylod in jmx notifications received by virtualized sensors), into a knowledge domain, how to render them into a composable information unit, removing its original nature of jmx:

package it.free.i.virtual.machine.hal.devicealias.echo;

import it.free.i.virtual.machine.hal.devicealias.command.DeviceAliasPortCommand;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.CenterOfMassPosition;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.LinearVelocity;

/**
* Positioning data DTO impl
* @author stefano
*/
public class PositionEchoImpl extends EchoImpl implements PositionEcho {

private CenterOfMassPosition centerOfMassPosition = null;
private LinearVelocity linearVelocity = null;
private DeviceAliasPortCommand deviceAliasPortCommand = null;

public PositionEchoImpl(){
super();
}

/**
* @return the centerOfMassPosition
*/
public CenterOfMassPosition getCenterOfMassPosition() {
return centerOfMassPosition;
}

/**
* @param centerOfMassPosition the centerOfMassPosition to set
*/
public void setCenterOfMassPosition(CenterOfMassPosition centerOfMassPosition) {
this.centerOfMassPosition = centerOfMassPosition;
}

/**
* @return the linearVelocity
*/
public LinearVelocity getLinearVelocity() {
return linearVelocity;
}

/**
* @param linearVelocity the linearVelocity to set
*/
public void setLinearVelocity(LinearVelocity linearVelocity) {
this.linearVelocity = linearVelocity;
}

/**
* Set the command that caused this response to be generated
* @param deviceAliasPortCommand is the source do read command
*/
public void setInitiaLDeviceAliasPortCommand(DeviceAliasPortCommand deviceAliasPortCommand) {
this.deviceAliasPortCommand = deviceAliasPortCommand;
}

/**
* Get the command that caused this response to be generated
* @return source command that caused the do read operation
*/
public DeviceAliasPortCommand getInitiaLDeviceAliasPortCommand() {
return this.deviceAliasPortCommand;
}


}
In other words: I have some setters and getters and values associated. I think that the name of the method could generally become the name of a property, whose value is obtained invoking that method. Doesn't matter the semantic of the name of the property, they just have not to collide each other or overlap (this approach satisfy this need and make it simple to see original data). Can be that every composable information unit is a bunch of key-value pairs, where the keys are the methods' names and values associated are the values obtained invoking the "keys" ? Of course a dto can have nested objects to render in a flattened representation (no nested objects please), so every dto must provide its rendered version because of the paradigm interface defining what a payload for jmx notifications is.