Here is the scenario:
I have an interface which defines get methods for data that will make
up a row in a table. However, the source of this data may, over time,
switch/change (The company may choose to change data providers).
Therefore i thought to myself, a type of Adapter Pattern is best here
and so i proceeded with that. here's an example of what i did (note
this implementation differs from the text book one due to the way data
must be handled...deleg ation would not be as clean here).
public interface IRowData {
public String getName()
public String getDescription( )
public float getValue()
public float getHigh()
public float getLow()
public float getNetChange()
}
public interface IDataAdapter() {
public void adaptData( Data data )
}
public interface IRowDataAdapter extends IRowData, IDataAdapter {}
*** Since the app needs the ability to easily switch from one data
provider to another, the Adapter Pattern seems ideal here. The app
receives real-time data. These data come in packets and different
packets contain different parts of the data that will constitute an
entire row. So here, my Adapter will have to differ a bit from the
standard Adapter design pattern. In this case, an Adapter actual
adapts many types of data to the interface i define above. it looks
something like this.
public class ACMERowDataAdap ter implements IRowDataAdapter {
private String _name;
private String _description;
private float _value;
private float _high;
private float _low;
private float _netChange; //calculated field
public String getName(){ return _name; }
...
public float getLow(){ return _low }
public void adaptData( Data data )
{
if ( data instanceof CompanyInfo)
//set _name and _description
else if ( data instanceof CompanyData )
//populate _value, _high, _low and calculate _netChange
}
}
In the above, code, I have simplified things greatly..but just assume
in this case the reason for this type of implementation of the Adapter
pattern is because simple delegation using the "adaptee's"
methods is not as easy or clean, esp considering some values are
calculated and data is from various types.
Ok, so here is my question finally. This data, IRowDataAdapter , will
represent one row in a JTable. So in essence, my TableModel will also
employ the adapter pattern, this time in the stricter sense,
implementing TableModel, and delegating to IRowDataAdapter . That table
may contain thousand's of rows, so performance is a concern. MY
QUESTION: wouldn't it be more efficient to break the "Adapting
code" out into a separate class, have one instance of that class that
takes a IRowData and populates it with data received? That way, you do
not have that "adaptData" method duplicated for ever row in your
table...that just seems like a waste of memory to me.
With the above implementation, EVERY ROWDATA carries with it some
unnecessary code (adaptData), with thousand's of objects, this could
add up, no?
In short, what is the best practice for this case...keeping in mind
speed is of utmost importance.
In the above, code, I have simplified things greatly..but just assume
in this case the reason for this type of implementation of the Adapter
pattern is because simple delegation using the "adaptee's" methods is
not as easy or clean, esp considering some values are calculated and
data is from various types.
Ok, so here is my question finally. This data, IRowDataAdapter , will
represent one row in a JTable. So in essence, my TableModel will also
employ the adapter pattern, this time in the stricter sense,
implementing TableModel, and delegating to RowDataAdapter. That table
may contain thousand's of rows, so performance is a concern.
MY QUESTION: wouldn't be more efficient to break the "Adapting code"
out into a separate class, have one instance of that class that takes a
IRowData and populates it with data received? That way, you do not
have that "adaptData" method duplicated for ever row in your
table...that just seems like a waste of memory to me.
With the above implementation, EVERY ROWDATA carries with it some
unnecessary code (adaptData) it seems, with thousand's of objects,
this could add up, no? Why not just have ONE class, with the following
method
public class ACMERowDataAdap ter implements IDataAdapter{
...
public IRowData adaptData( IRowData appData, Data foreignData)
{...}
...
}
In short, what is the best practice for this case...keeping in mind
speed is of utmost importance.
