What is the difference between those two approaches [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

Proceeding

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.

Brosy

Thanks for your detailed answer! I have two points that remains unclear ( I am not an english native speaker... :/ ). 1. What is meant exactly by a protocole of a class? is it the set of all its methods and properties? 2. In the first (bad) case the client needs to call the method #withoutDuplicatesDo in which there is a conversion and there is something todo with the converted object as well but in the second (good) case, it calls only the conversion and then do whatever to do with it. Am I right? – Proceeding

1. Exactly. Note however that in Smalltalk we only have methods (not properties). 2. You are right. – Brosy

@SomeThoughts: If you know Java, then you can think of protocol to be like interface. That is not a coincidence: The main influence on Java was Objective-C, which has a concept called protocol, and Java's interface is a direct clone of that. Objective-C's object system, in turn is identical to Smalltalk's (it is essentially Smalltalk's object system bolted onto C), so the language concept protocol in Objective-C is basically the same as the concept of protocol in Smalltalk. – Astyanax

@SomeThoughts: Another way to think about it is that what we call a protocol in Smalltalk would be a type in other languages. And a third way to think about it is that Alan Kay was heavily inspired by message-passing networking, and in particular by what was about to become the Internet. Objects are like machines on a network, instance variables are like RAM, and how do machines on a network communicate? Using protocols! – Astyanax

@JörgWMittag What a great historical insight about Alan Kay ! Thanks <3 – Proceeding