On Jun 17, 2010, at 11:26 AM, Geoffrey Garen wrote:
>> I propose that we create an abstract class, "PlatformMechanism" which acts
>> as the starting point for accessing such functionality, something like:
>>
>> class PlatformMechanism {
>> virtual ClipboardMechanism* clipboardMechanism() = 0;
>> virtual FileAccessMechanism* fileAccessMechanism() = 0;
>> virtual PluginMechanism* pluginMechanism() = 0;
>> };
>
> I think this would read better if you just got rid of the "Mechanism" suffix.
> It's such an abstract word that it's maybe meaningless.
>
> You might still need something to distinguish this kind of clipboard from,
> say, the WebCore clipboard. For that, I suggest using the word "platform."
I agree that Mechanism is a very vague word. Platform is an interesting idea,
but I believe it is potentially confusing in some ways. We have normally used
platform/ to refer to stuff in the Platform directory. In fact we already have
a Clipboard class in WebCore/platform, the role of which is platform
abstraction of the underlying implementation. The proposed PlatformClipboard
object would not primarily be providing platform abstraction, rather its main
role is to provide runtime switchability among different implementations, one
of which is a cross-process proxy and the other of which implements clipboard
functionality directly. I don't think the name PlatformClipboard clearly
identifies how the role is different from Clipboard, given the context of the
project.
Cracking my Design Patterns book (or at least my memory of it), another idea
that comes up is "Strategy". Strategy is a design pattern where you have a
runtime switchable object that provides alternative approaches to providing the
same functionality. Then we would have:
ClipboardStrategy --> abstract class
ClipboardProxyStrategy (or ProxyClipboardStrategy) --> class that provides the
details of clipboard functionality by proxying to a privileged process
ClipboardDirectStrategy --> class that implements clipboard functionality
directly.
Then Clipboard makes use of an abstract ClipboardStrategy, without having to
know which implementation it is using under the covers. And
ClipboardProxyStrategy could even be implemented using ClipboardDirectStrategy
on the other side of the proxy.
I'm not sure if that is the best naming, but I often find the Design Patterns
book helpful for naming classes that have an abstract role which is hard to
describe succinctly.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
