这两种方法有什么区别[Smalltalk Best Practice Patterns - Kent Beck]？

Question

How to convert information from one object's format to another?

In Smalltalk best practice patterns by Kent Beck , he discouraged "adding all the possible protocol needed to every object they may be asked of it". Instead, he suggested to convert from one object to another.

Can someone give me an example of what he meant by "overwhelming object's protocol"? I am trying to understand the bad way to do it in order to be able to appreciate the good way.

Reference: Smalltalk by best practice patterns - Page 28

Answer 1

As Beck explains, some clients may need to enumerate a collection in a way that the elements are sorted before exposing them, others would require not iterating twice over the same object (which may appear twice in the collection), etc.

One way to address these situations would be to add methods such as #sortedDo: , #withoutDuplicatesDo: , etc. to the collection class. Sooner or later, this approach would derive in populating the class with other variants of #do: such as #sortedSelect: , #withoutDuplicatesCollect: , and the like. The problem is that the resulting protocol of the class would quickly grow too large, adding complexity to the simple task of finding the right selector, increasing the risk of duplicating pieces of code when the search is not exhaustive enough, etc.

To avoid those side effects, the class should provide methods for converting its instances in instances of other classes. So, instead of #sortedDo: the client may use

aCollection asSortedCollection do: aBlock

or

aCollection asSet do: aBlock

for iterating without duplicates.

This explains why we have abundant conversion methods: #asArray , #asOrderedCollection , etc. Note also that conversion methods are not restricted to collections, they are also available for other classes: #asInteger , #asFloat , #asString , #asSymbol , etc. Thanks to them, the services that clients usually need can be obtained by combining a conversion with the appropriate message, without overwhelming the class of the object at hand with all possible combinations, which would multiply (rather than add) all the possibilities.