|
[
Permlink
| « Hide
]
Dave Syer added a comment - 11/Feb/08 01:22 AM
"Adapter" is just as common as "Support" in Spring Core, and I think we prefer Adapter overall. Do you have a strong counter-argument?
Compare to ItemReaderAdapter and ItemWriterAdapter --- despite being used prolifically, we can at least be consistent with the way we use each one. Adapter, as it is used in the forementioned classes, is close to if not exactly the model of the Adapter design pattern (i.e. takes an object of one type and adapts it to another). Support, as it is used elsewhere in Spring Batch, simply means defining some default basic functionality that all subclasses will want (or some blank implementations so subclasses don't have to explicitly define them).
"Adapter" is unfortunately already used to mean the same thing - i.e. an empty methods implementation for base classes to extend (and even the JDK is not consistent about this, c.f. PropertyEditorSupport and the various *Adapter in javax.swing).
I was more concerned about being consistent within our own framework - how we use adapter vs. support should be consistent, even if the world at large is not. (That said, yeah the world should be consistent too, but we can't enforce that. We can police our own code though)
Depends... Are you changing all supports to adapters to make this a non-issue, or are you just changing classes to make usage more consistent?
Lucas asked me to comment on this, so here it is:
Adapter and Support do not mean the same thing. As Doug mentioned, Adaptor has a clear definition that has existed since 1994 when the GoF published it. Using the Adapter suffix to refer to anything other than an application of the Adapter pattern is counterintuitive and poor style. For Support, we look to the dictionary. "3 Computing (of a computer or operating system) allow the use or operation of (a program, language, or device)" It would seem that any class that enables the functionality of another would be a Support class. So it seems that Adapter is the square and Support is the rectangle. Adapters are support classes because they enable one object to be used by another, but Support classes are not necessarily Adapters because a vast array of classes using various patterns can provide support. So, TaskletAdapter is certainly an Adaptor, but ItemStreamAdapter is not. And finally, Spring Core seems to support this idea (for the most part). http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/core/task/support/ConcurrentExecutorAdapter.html adapts TaskExecutor to Executor http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/dao/support/DaoSupport.html provides common funtionality but doesn't adapt anything to anything else, so it's a Support class. The two above examples are good ones from Spring Core. But, you can always find bad examples, such as TransactionSynchronizationAdapter, which is just a no-op implementation of the TransactionSynchronization interface.
In general, I also prefer reserving *Adapter to classes that actually adapt functionality. Given what ItemReaderAdapter does (adapting the ItemReader interface to the MethodInvokingDelegator) I agree with keeping it an Adapter, but it doesn't make sense to change JobSupport and StepSupport to be JobAdapter and StepAdapter respectively. If I had my choice, I would drop Support altogether and use Abstract* for classes providing base behaviour and reserve Adapter for things that are adapting one thing to another. Something ending in *Suport has always felt weird for me as a base class. I would personally rather extend BaseJdbcDao or AbstractJdbcDao rather than JdbcDaoSupport as-is picture of ItemStreamAdapter.
[retype - meant for text to be with jpg]. I don't have a strong opinion about the use of <Support> as a stereotype but I would like to comment on the core topic here, whether ItemStreamAdapter is named correctly. I'm of the feeling it is not. I've added a visualization to help others weigh in. I personally believe, like Greg, that Adapter is a well understood pattern. I like Steve Metsker's test of answering to yourself whether a candidate <adapter> passes the "this class as the class I'm adapting". In his Design Patterns Workbook he uses the RocketAsShell example. I also personally don't care for abstract classes that have no abstract methods, especially when they abstract classes that did provide behavior.
Here's my proposal, and I'd be glad to do the cleanup if people agree. 1. Rename ItemStreamAdapter to whatever the right name for an implementing class is in Spring. I don't know the naming standards well enough. We would normally have just created ItemStreamImpl but I understand that doesn't pass mustard for Spring class naming. 2. Remove the AbstractClasses that have no behavior - this would be AbstractItemStreamItemReader, AbstractItemStreamItemWriter. The only one not renamed is AbstractTransactionalIoSource, which after refactoring is probably better renamed as AbstractTransactionalItemReader but only if the group agrees. This would resolve and close this issue. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
ItemStreamAdapter isn't an Adapter
