On 10/08/2010, at 7:06 PM, Geoffrey Holden wrote: > I'm writing an app which communicates with a server. The protocol that it > uses is subject to change, so I'm writing a plugin to support that > particular protocol. When, in the future, the protocol changes (as it > probably will), I'll only need to change the plugin and not the entire app. > That's my thinking anyway. > > Sometimes, the server will send an update message out - my plugin can > respond to these events correctly, but (obviously) I need my app to - so, > effectively, I need to find a way of delegating the response to the app (the > plugin needs to pass the event on).
I don't know that I can comment on your specific protocol - do whatever makes sense. As a matter of general design though, perhaps a better way to set this up is to have some controller object implement the general form of the system, but defer to another object to provide the specific implementation. The plug-in can then insert whatever object it needs to in this position when it is loaded (modulo dealing with the presence of multiple plugins, multiple protocols). In other words do it the other way around - don't get the plug-in to do a lot of complicated work and hand off to the app as needed, get the app to call an object the plug-in put there. This approach is a lot easier to test too, since you can insert a test object without even needing a plug-in. In a procedural/static language, plug-ins can be complicated, needing all sorts of communication protocols set up between the host app and the plugin that everyone agrees on. In Cocoa, almost any sort of plug-in design becomes, if not trivial, then at least orders of magnitude easier, because of a) the existence of objects and b) the dynamic nature of Obj-C. Usually it's enough to load the plugin and then give it a chance to run at certain well-defined times (e.g. when it is first loaded, app launch, as each document is created, etc.). At those times the plugin simply manufactures suitable objects and inserts them into the app where they take a normal role in the business of the app. The fact that the code that implements these objects is part of the plug-in's bundle makes no difference. In other words, a plugin is merely a factory for other objects that get the work done. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
