Josias Thöny wrote:
[...]
which I think should apply for all "components" working on resource
types:
Creator
Editor
Indexer
Publisher
LinkRewriter
....
If we allow this, we would also need a resource-type specific Mover,
Copier, Deleter, Deactivator, Revisioner, ...
To clarify this from an OO development point of view:
Thorsten proposes to allow resource-type specific polymorphic behaviour
of components in the document management API. But polymorphism is only
applicable for purely interface-based architectures:
+--------+ +---------------+ +-------+
| Client |--->| <<interface>> | +---| ImplA |
+--------+ | Service |<|---+ +-------+
+---------------+ |
| +-------+
+---| ImplB |
+-------+
You run into serious trouble if you allow polymorphism for
internal components:
+--------+ +------+ +------+ +-------+
| Client |--->| Serv |->| Copy |<|-+---+ CopyA |---+
+--------+ +------+ +------+ | +-------+ |
| | |
| | +-------+ |
| +---| CopyB |---+
| +-------+ |
| |
| +--------+ |
+---->| Source |<----------------+
+--------+
If you change the internal Source class later on, the
CopyA and CopyB implementations will fail.
So you would have to add internal details (e.g., how sources
are accessed) to the public API to allow the customer to add
different implementations of the Copy component.
Adding former internals to the public API would lead to a
massive increment of the size of the public API, with the
following implications:
- breaking up encapsulation will decrease safety
- the API becomes more complex and harder to understand
- development agility will be lost
- changes will be avoided to ensure backwards compatibility
Usually, the goal is to design an API so that the complete
desired behaviour can be accessed using a minimal set of
operations. If you want to achieve flexibility and a minimal
API at the same time, you have to reduce the provided
functionality. Compare, e.g., JCR with Lenya. JCR is much
more flexible, but Lenya is more powerful regarding document
and asset management functionality.
With Thorsten's proposal we will gain flexibility, but we
should be aware of the downsides of this approach.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
