Thanks for taking the time to read it and provide feedback! Comments inline.
On Wed, Feb 17, 2010 at 8:04 AM, jarrod <[email protected]> wrote: > > However, a side effect of this solution is that dependent classes > (your ButtonPanel, in this example) must now be updated to rely on the > *Shim class instead of the original class used before the shim. > > One of the tenets of dependency injection is that you should be > injecting dependencies according to interface, not implementation (see > Martin Fowler's explanation: > http://www.martinfowler.com/articles/injection.html#InterfaceInjection). > So your dependent classes shouldn't have to change when your > implementation changes, nor should they care what type of > implementation they receive. > So if you're following this tenet, you have Module (interface with public API--and ONLY the public API, and by "public" I mean available to consumers on the far side of the split point) and ModuleImpl (class) today, right? > So in that regard, while using the shim may provide a nice way to > abstract some boilerplate, it does break your existing API contracts > and it requires that you define new *Shim contracts that are likely to > duplicate existing API contracts. > I didn't get into this with my blog post, but if you do already have Module and ModuleImpl, your ModuleShim can merely declare that it implements Module. No need to re-declare the API. The deferred binding code will find ANY method that returns void and is not implemented. In other words: class ModuleShim extends AsyncShim<ModuleImpl> implements Module {} If I'm understanding you correctly, nothing needs to change with the callers. But you do then need to change your Gin module binding to point to ModuleShim. > If the underlying implementation in the shim is to be created and > delegated to asynchronously, then it is true that each shimmed method > must return void (similar to the RPC async interfaces), and that > imposes some limitation on what we can readily abstract. > That's true, but no more so than any other solution where code outside of a split point needs to cross the split point boundary. If you want a result value, you'll have to pass in a callback rather than just use a return value. Code that's on the same side of the split point as ModuleImpl can continue to call methods on it directly and synchronously. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
