4 ms·

The author contrasts "objects" and "ADTs" (abstract data types), but uses - to my mind - an improvished definition of ADTs. I've always thought of On the criter

by hyp0 12y ago

The author contrasts "objects" and "ADTs" (abstract data types), but uses - to my mind - an improvished definition of ADTs. I've always thought of On the criteria to be used in decomposingsystems into modules (Parnas) as the key paper for ADTs, which the author cites (at [26]) but doesn't use for this purpose. Of course, different definitions are available. The distinction the author uses is that objects can have different implementations, but ADTs can't. From this follows a streams of motherhoods of the advantages of having different implementations. Curiously, from my scan, he doesn't seem to mention evolution of interfaces. That is, instead of evolution being just a different implementation of an identical interface, it is much more common for something to be added: extra data, extra services, extra features. The typical approach is to leave everything the same (so that old clients still work with this new API), and strcitly only add new methods (and/or types with superset values). My reasonably involved studies of the evolution of Java classes in the standard packages for the purposes of serialization (which must store and recreate them), showed me that in practice, it's pretty rare for an implementation to change without the interface also changing. That is, I'm claiming: Interface evolution is more common than implementation evolution alone. To be clear: although implemenation evolution can and does occur (e.g. intern aspects of String recently), it's pretty rare to occur without the interface also changing. Not counting simple bug-fixes, which don't substantially change the implementation, and also not taking into account interfaces that were initially designed to have multiple implementation (e.g. collections, swing/awt, some networking classes etc), as these aren't evolution. (Though, I suppose adding a new implementation of existing interfaces e.g. LinkedHashMap (ordered map) counts as "evolution".) This higher frequency of interface evolution may be a reflection that we get paid for features, not refactoring.

discreteevent 12y ago
You can't have large flexible systems of any kind without some sort of fixed interfaces or protocols. There must be millions of examples. Sockets, ODBC, drivers, USB, nuts and bolts etc etc.
- hyp0 12y ago
  you skipoed parts of my comment: you can have those bnefits, by backcompatibility, which you do by evolving only by adding, not changing the part of the interface that is already there. All those examples you mention evolve, with later versions adding features that require the interface to be added to. They aren't "fixed", they are "backcompatible". This also applies implicitly to any client for interop: you don't have to use the whole interface, just the festures you want. In effect, you are using different, smaller interface.

by hyp0 12y ago

discreteevent 12y ago

You can't have large flexible systems of any kind without some sort of fixed interfaces or protocols. There must be millions of examples. Sockets, ODBC, drivers, USB, nuts and bolts etc etc.

hyp0 12y ago
you skipoed parts of my comment: you can have those bnefits, by backcompatibility, which you do by evolving only by adding, not changing the part of the interface that is already there. All those examples you mention evolve, with later versions adding features that require the interface to be added to. They aren't "fixed", they are "backcompatible". This also applies implicitly to any client for interop: you don't have to use the whole interface, just the festures you want. In effect, you are using different, smaller interface.