Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: True O-O [Was: double == double] Date: Wed, 19 Oct 2016 22:09:01 -0400 Organization: Aioe.org NNTP Server Lines: 82 Message-ID: References:

<8737k0qd38.fsf@golem.phantasia.org> <87zim5es30.fsf@golem.phantasia.org>

NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:35844 On 10/17/2016 6:06 PM, Eric Sosman wrote: > On 10/17/2016 5:11 PM, Patrick Roemer wrote: >> >> In OO, one usually sends messages to objects, which triggers operations >> on their encapsulated state. Java's Math.max() is not how OO is >> "normally" done in my book. > > As someone who is most definitely not a dyed-in-the-wool O-O Expert, > I'd be interested to hear your opinion of things like, say > > Collections.sort(theList); > > vs. > > theList.sortYourself(); // fictional, today > > It seems fairly normal to me that some operations are "built into" the > classes, while others are "imposed from without," although the criteria > for choosing between the approaches may not always be perfectly clear. > This is especially true of operations not anticipated at design time; > I can more easily imagine adding a > > Collections.getMedianElement(theCollection); // fictional > > than I can imagine adding a > > theCollection.getMedianElement(); // fictional > > to every Collection subclass. > > What's the Righteous O-O Way here? Drag out more interfaces? > > interface SortableList extends List { > void sortYourself(); > } > > interface MedianAwareCollection extends Collection { > T getMedianElement(); > } > > ... > > That doesn't seem very attractive, as one would need to keep in mind > which of the various Lists are or are not also SortableLists. Sure, we > have Set and SortedSet (and we know that TreeSet implements both while > HashSet implements only Set), but I imagine that things would soon get > out of hand with the addition of BinarySearchable and Reversible and > Rotatable and Shufflable and ... All true. But I think somewhat besides the point. Classes work on other classes all the time. But the Version as String was a lot more than that. The String type did not contain any information about the format and how it could and should be processed. The list send over is an interface and Collections are (I assume) using the public methods of that interface. The Comparator had to have explicit knowledge about the format of the String with version info to process it. In that sense it is more like if Collections.sort used reflection to get the actual type and if it was an ArrayList then it used reflection to get the array behind. That would be bad. Collections.sort should not know about how a common List implementation stores its internal data. Just like a Version Comparator should not know about string formats. Arne