what design pattern is this?

[farseer]

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...delegation 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 ACMERowDataAdapter implements RowDataAdapter {
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 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 ACMERowDataAdapter 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.

 

[Ross Bamford]

Here is the scenario:

Generally speaking, this is a mess. If something is conditional on being
of a certain type, then it should be a type in it's own right.

I would look into Hibernate. Perhaps it's no good for your particular
case, but I'd doubt that...

www.hibernate.org

In short, what is the best practice for this case...keeping in mind
speed is of utmost importance.

Of development or execution? My previous suggestion would fulfil both if
executed properly

 

[farseer]

i really do not want to rely on third party tools as this needs to be
light weight..it will ultimately be an applet. Hibernate seems to be
more like jaxb and related to database object mappings. Can you tell
me how this will help?

Also, you stated this is a mess. Why do you say that? In short, the
model here is:
-the app knows about the data it uses. There exists data objects
representing this data on the client side. The app only intefaces with
these data objects.
-the data adapter simply allows a "pluggable" feed. in other words, an
adapter to conform incoming data to the client's interface can easily
be created by simply creating a class that implements IDataAdapter.

My quetion here really is about the Adapter Pattern. Most examples i
have seen follows the "book" strictly. that is, an Adapter Class
implements an interace an extends another class to allow for adaptation
of one to the other. In the above case however, there may more than
one class necessary to adapt to the interface. Additionally, from a
performance standpoint, why use the "Textbook" adapter pattern when in
this case we could save much resource by creating a class that simply
knows how to populate a class that the client application is expecting
from various other objects. This way, we decouple the adapting code
from the actual data objects that are used to populate the data table
rows.

 

[Ross Bamford]

i really do not want to rely on third party tools as this needs to be
light weight..it will ultimately be an applet. Hibernate seems to be
more like jaxb and related to database object mappings. Can you tell
me how this will help?

Okay fair enough, I'd misinterpreted your data needs a little...

Also, you stated this is a mess. Why do you say that? In short, the
model here is:
-the app knows about the data it uses. There exists data objects
representing this data on the client side. The app only intefaces with
these data objects.
-the data adapter simply allows a "pluggable" feed. in other words, an
adapter to conform incoming data to the client's interface can easily
be created by simply creating a class that implements IDataAdapter.

I can see the model you're going for, but you've got it kind of upside
down. The mess is your inheritance model, but if it works for you then
it works for you... You just seem to be going places that people have
already been.

My quetion here really is about the Adapter Pattern. Most examples i
have seen follows the "book" strictly. that is, an Adapter Class
implements an interace an extends another class to allow for adaptation
of one to the other. In the above case however, there may more than
one class necessary to adapt to the interface. Additionally, from a
performance standpoint, why use the "Textbook" adapter pattern when in
this case we could save much resource by creating a class that simply
knows how to populate a class that the client application is expecting
from various other objects. This way, we decouple the adapting code
from the actual data objects that are used to populate the data table
rows.

But do you? Or do you just abstract one more level away from it?

In any case, you stated originally that your reason for going down this
road was the 'duplication of the adaptData method', which is a
fundemental misconception. If I have a class, DataAdapter with that
method, and I have twenty, fifty, or ten million instances of
DataAdapter, there will still be only one copy of the /method/, i.e. the
bytes making up it's code and descriptor. This is kept with the Class.

So you see, not only is your implementation backward (adapting from
above), but it's also needless.

See also discussion (recent and less so) about instanceof in /exactly/
this type of situation...

 

[farseer]

ok, thanks much for your response. so what you are saying is that
their really is no advantage, performance wise, gained from abstracting
out the actual Adapting code into a separate class, correct? then the
only question is whether the design/architect is sound.

What do you mean by "but you've got it kind of upside down...You just
seem to be going places that people have
already been."?

thanks again for you comments, this is helpful.

 

[Ross Bamford]

ok, thanks much for your response. so what you are saying is that
their really is no advantage, performance wise, gained from abstracting
out the actual Adapting code into a separate class, correct? then the
only question is whether the design/architect is sound.

Not in the way you suggested, no. I /would/ certainly recommend
abstracting the adaptor code, but implementing it /down/ the line. With
an adaptor you should be 'wrapping' an instance of your 'adaptee' and
delegating to it's methods as appropriate.

Consider this:

// =====
public interface StringEmitter {
public String emit();
}

// -----
public class RegularEmitter implements StringEmitter {
public String emit() { return "Emitted"; }
}

// -----
public class ReplacingAdaptor implements StringEmitter {
private StringEmitter adaptee;

public UpperEmitterAdapter(StringEmitter em) {
this.adaptee = adaptee;
}

public emit() {
return adaptee.emit().toUpperCase();
}
}

// =====

There are a few points to note:

1) The base emitter is an interface.

2) The basic implementation is a simple concrete implementation of that
interface.

3) The adaptor is /also/ a simple implementation of that interface. It
doesn't subclass the basic implementation. Thus, the adaptor is not tied
to any particular subclass hierarchy, but can adapt any StringEmitter
without knowledge of it's internals, and the adaptor can be passed
around at will.

4) There is no separate adaptor interface, and no 'adaptData' method.
The adaptation is implicit in the hierarchy, and nowhere do we have our
possible types 'compiled in'.

Now, your situation is a little more complex, but is still basically the
same. Continuing the example above, I could have:

public interface MutableStringEmitter extends StringEmitter {
public change(String newString);
}

public interface FixedLenStringEmitter extends StringEmitter {
public int maxLength();
}

etc.

This is of course purely demonstrative, but you can see already that
with this pattern we do not require foreknowledge of the object type to
utilise it's common properties, but we do require such knowledge to
access those extended properties. This makes sense, since it would be
folly to obtain the maximum length without knowing if the emitter
even /has/ a maximum length, for example.

http://c2.com/cgi/wiki?AdapterPattern

thanks again for you comments, this is helpful.

Always happy to help

 

[Wibble]

Agree with Ross.

r really is no advantage, performance wise, gained from abstracting

 

[farseer]

Ross,
i agree with you and in fact, that was exactly how i started
implementing this. However, i ran into some difficulties with this.
in my case, there are serveral adaptees that are required to be able to
delegate to the interface the application knows about and expects.
Also, at some point, unfortunately, i will need to inspect what kind of
obect/data these adaptees are to know how to properly delegate. The
good thing is, in both the text book case (as you described), and the
case i am suggesting, all that logic is in the adapter class itself.
Further, in the case i am suggesting, this logic is buried in the
interface method adaptData, which means the application or client code
DOES NOT need to know about these different type of data objects at
all.
lastly, the primary reason i guess i decided to go with the modfied
version of the Adapter design pattern is that in my case, it is not
just a simple delegation of adatee methods to interface. in many
cases, there needs to be some processing and conversion of the incoming
data (code look up, calculations, etc). If i were to use a delegation
model, each time client accesses those methods, that calculation would
be run unnecessarily.
With the model i chose to use, i am basically "polulating" an
implementation of the interface, an implementation that the application
expects anyway and one with simple get and set methods, so no
performace hit is taken when accessing these methods several times.

as always, thanks much for your comments.

 

[Wibble]

Why did you post this thread? Looking for validation for your kookie
design?

 

[farseer]

thanks wibble.

regards,
mike

 

[Ross Bamford]

Ross,
i agree with you and in fact, that was exactly how i started
implementing this. However, i ran into some difficulties with this.
in my case, there are serveral adaptees that are required to be able to
delegate to the interface the application knows about and expects.

I'm not sure I've got you correctly here, but it sounds like you need
another layer between the two.

Also, at some point, unfortunately, i will need to inspect what kind of
obect/data these adaptees are to know how to properly delegate. The
good thing is, in both the text book case (as you described), and the
case i am suggesting, all that logic is in the adapter class itself.
Granted...

Further, in the case i am suggesting, this logic is buried in the
interface method adaptData, which means the application or client code
DOES NOT need to know about these different type of data objects at
all.

I'd disagree. In fact, I would suggest that the data-types themselves
have actually become a part of your design.

lastly, the primary reason i guess i decided to go with the modfied
version of the Adapter design pattern is that in my case, it is not
just a simple delegation of adatee methods to interface. in many
cases, there needs to be some processing and conversion of the incoming
data (code look up, calculations, etc). If i were to use a delegation
model, each time client accesses those methods, that calculation would
be run unnecessarily.

A more conventional solution might be to cache these expensive results
in your adaptor, after (possibly lazy) calculation (on first use).

With the model i chose to use, i am basically "polulating" an
implementation of the interface, an implementation that the application
expects anyway and one with simple get and set methods, so no
performace hit is taken when accessing these methods several times.

I think you are considering the most irrelevant issues with respect to
performance. As often discussed in this newsgroup, JVM performance is
not equivalent to Emulator performance - it doesn't suffer the same
issues /at all/.

At the end of the day, if this design is working for you, and you'll
never have to justify your decisions, then why the hell not... You could
move your adapt data method around and what have you, because while
there aren't any real performance gains to be had, there aren't any real
penalties either.

I have to respect your willingness to stand by your design, and would
certainly say that, if you feel it is the best way to go, then do it!
Patterns, tech tips and newsgroups are all there to help but some of the
best software in history was written in a flash of inspiration. It is a
common situation these days for a project to stagnate and die because of
constant redesign to fit the current 'Best Practice' (as opposed to
because the software really needs it).

 

[farseer]

Ross,
As i have stated, you have been a great help and i have/will take all
you have advised into consideration. Often times, i find that simply
having someone there to review, criticize and discuss a design in a
civil and non-combative manner is unltimately what helps me the
most...rather than those that simply choose to attack without offering
any substance or insight into why they feel so strongly.

I truly appreciate you taking the time to respond.

cheers.

 

[Ross Bamford]

Often times, i find that simply
having someone there to review, criticize and discuss a design in a
civil and non-combative manner is unltimately what helps me the
most...rather than those that simply choose to attack without offering
any substance or insight into why they feel so strongly.

I'm a big believer myself ... An idea is pretty one-sided until you
bounce it around. I feel that those who make such attacks prove only
that their arguments lack either substance or insight, or both.

Anyway, glad to have helped...