Gary Poster wrote:
Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to the wall (output interface). Is there a common real-world example of this for "multiadapters"?
It's a good question. Plugging a power cord in on both ends? :) Slightly more seriously, a lego brick connecting to multiple other bricks? But that isn't a good enough answer to that question.
3) I also think that "utility" is a bad name. Is "singleton" two letters too long? If it is, I mind "utility" less than I mind "adapter". I don't understand this. For me a singletons is (sic) a highly specific programming term whereas adapters and utilities, especially in the way we refer to them, are not so domain specific.
Turned around, people know the term "singleton" and they do not know the terms "adapters" and "utilities". "singletons" describe the huge majority of how we use these things. It's something less to explain. Making comprehension quicker is very valuable to me.
I don't like the word singleton very much either. Singleton in the Design Patterns book has a very particular implementation that is criticized by a lot of developers and in particular that particular pattern is very uncommon in the Python world (people just use globals). I think introducing the term would pull in all that baggage to a newcomer. Just type in 'singleton' in Google and you'll get the wikipedia definition: In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. Utility classes are *not* restricted to a single instantiation. Now we can argue successfully that's an extension of the singleton principle, but then we've lost a lot of people already who thought they knew (or went to lookup) what the word "singleton" means. Regards, Martijn