From: Hiroo H. <hir...@co...> - 2004-08-01 19:34:37
|
Torsten and Rib came back. And Joachim joined us. During Torsten's and Rib's absent I've done many of issues on my TODO list. Shall we restart discussion of interface structure? On Mon, 03 May 2004 16:54:30 -0700 (PDT) Rib Rdb <ri...@ya...> wrote: Rib> Attached is a jar file containing possible interfaces for Driver, Rib> BankDriver and Patch. Also included is an abstract parent class of Rib> device containing methods that should be common to all devices. I Rib> used interfaces for drivers so that a synth can have a bank driver Rib> that is a subclass of any Driver (or IDriver for that matter). (For Rib> example, I wanted YamahaMotifBankDriver to extend Rib> YamahaMotifSingleDriver). I will also upload the jar to yahoo groups Rib> since i don't think message attachments are archived. Here is my idea. 1. interface IDriver (I don't have good name for this now.) This is an interface for Device.driverList. All of drivers (single driver, bank driver, converter) implement this. public String getPatchType(); public String getAuthors(); public boolean supportsPatch(StringBuffer patchString, Patch p); 2. class Converter implements IDriver abstract public IPatch[] extractPatch(IPatch p); I don't think we need to define interface for converter. 3. interface IPatchDriver extends IDriver This includes methods shared by ISingleDriver and IBankDriver which are used by LibraryFrame, etc. 4. interface ISingleDriver extends IPatchDriver This includes methods only for Single Driver. 5. interface IBankDriver extends IPatchDriver This includes methods only for Bank Driver. Note 1: This requires no change in synth drivers. Note 2: These interface includes only methods which core class uses. In other words they do not include methods which are used only by extending drivers. For example the followings are not included in ISingleDriver. public void send(byte[] sysex); public void send(int status, int d1, int d2); public void send(int status, int d1); Note 3: IBankDriver does not extend ISingleDriver. It is simply because a bank driver does not extend a single driver, but (sometimes) uses single driver methods. IBankDriver does not need all methods ISingleDriver. And a BankDriver uses same name methods with its Single Driver. It each method on BankDriver does not extend one of SingleDriver, but uses it. This is the reason I propose to pass a SingleDriver object to BankDriver constructor. Here is Rib's reply which I've not answered yet. On Tue, 04 May 2004 00:57:09 -0700 (PDT) Rib Rdb <ri...@ya...> wrote: Rib> --- Hiroo Hayashi <hir...@co...> wrote: Rib> > I used interfaces for drivers so that a synth can have a bank Rib> > driver Rib> > that is a subclass of any Driver (or IDriver for that matter). Rib> > Rib> > (For example, I wanted YamahaMotifBankDriver to extend Rib> > YamahaMotifSingleDriver). me> I think what you want to do can be done by passing the Single me> driver object to the constructor of the bank driver as I do in me> RolandTD6 driver. me> Here is the part of constructor RolandTD6Device. me> me> // add drivers me> TD6SingleDriver singleDriver = new TD6SingleDriver(); me> addDriver(singleDriver); me> addDriver(new TD6BankDriver(singleDriver)); Rib> Hmm. I suppose this would work, although it's not as elegant as Rib> simply being able to say "MyBankDriver extends MySingleDriver Rib> implements BankDriver". My proposal is just saying "MyBankDriver implements IBankDriver". First I tried to use 'super' in my TD6 BankDriver but it did not work well. It's not extending the Single Driver but only uses it. Having single driver object in the bank driver made the code straight forward and simple. I've been having a question. Who calls Driver.calculateCheckSum(IPatch), code in core or synth driver? It seems that now both call it, because it is not clear. If it is core's responsibility, each synth driver does not have to call it. If it is a synth-driver's responsibility, we can drop it from Interface. -- Hiroo Hayashi |