Cart
[Home] [By Thread] [By Date] [Recent Entries]
> > At a purely practical level, I'm constantly wishing I could > > dynamically change an ArrayList into a LinkedList without having to > > know about all the places that might hold a reference to it. > > Could you please elaborate where this scenario has a > practical use (i.e., at run-time, or within a running > process/thread an ArrayList can be treated as a LinkedList) ? > > In Java, ArrayList and LinkedList both implement the List > interface. I think, in a statically typed language like Java, > what you say might not be possible. I think, in Java to > implement your idea (i.e., swapping ArrayList and LinkedList > behaviour), we can design a new type (some form of list). > You've got two different classes that implement the same interface, but they have different performance trade-offs. But you have to decide which one to use "in advance". If you want to change your mind later - for example if the size grows to a certain level or if you notice a certain usage pattern, it would be nice to switch over to a different implementation. But you can't do that without changing the identity of the object, which means you need to tell everyone who holds a reference to the object to update their reference. Of course all problems in computing can be solved by adding a layer of indirection. You can design a wrapper object that implements the interface and delegates all the work to either an ArrayList or a LinkedList. This wrapper object is the only object to know about the implementation object so only one place has to change when the implementation changes. But it would be nice if this were built into the language, not something you have to program yourself. Apart from anything else, forwarding all the method invocations is expensive. Here's another example from the XML world: it's a quirk of the XSLT specification that you don't necessarily know what serialization method you are using until you write the first element node, and by that time you can have written lots of comments and processing instructions (which the serializer has to buffer, because their final output format depends on the serialization method chosen). It's a reasonable design to have an HTML serializer and an XML serializer that share the same interface to the rest of the system; it would be nice to have a single serializer object that initially is a wait-and-see serializer, and that later converts itself into either an HTML serializer or an XML serializer without the client needing to know anything about the change. We came to this though from a data modelling perspective where the benefits are even greater. If I've got three types, employee, pensioner, and shareholder, and if a single person object can change its membership of these three types over time, with a persistent identity that can survive a change of type, then I have a much more accurate model of reality. If an employee is a shareholder I only want to record his address in one place. And I can use the common identity of the employee and the shareholder to answer questions. Who is the author of this document? He's John Smith, who was an employee until March last year but is now retired, we know his current address because he still holds some shares in the company and receives dividends. I believe the motto used by Bill Kent (one of the IRIS designers) was "identity should be orthogonal to type". It's one of those brilliant ideas that for some reason never became mainstream and will probably be relaunched by Microsoft as a sensational innovation in about 20 years' time. Michael Kay http://www.saxonica.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
