Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #35844
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: True O-O [Was: double == double] |
| Date | 2016-10-19 22:09 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <nu98vt$h9o$1@gioia.aioe.org> (permalink) |
| References | (17 earlier) <be7ba475-196e-4269-8b6e-e4a88f8305f1@googlegroups.com> <nu30a0$j0r$1@newsreader4.netcologne.de> <nu382t$pf6$1@dont-email.me> <nu3eq2$tv6$1@newsreader4.netcologne.de> <nu3hvn$ss8$1@dont-email.me> |
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<T> extends List<T> {
> void sortYourself();
> }
>
> interface MedianAwareCollection<T> extends Collection<T> {
> 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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-12 09:39 -0400
Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-13 21:10 +0200
Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-15 14:04 +0200
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 09:13 -0400
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 10:32 -0400
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 10:46 -0400
Re: double == double Michael Jung <miju@golem.phantasia.org> - 2016-10-15 17:44 +0200
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 17:36 +0100
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 14:15 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 19:41 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 20:39 -0400
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 10:41 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-15 23:09 +0100
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-15 18:28 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:13 +0100
Re: double == double Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-16 08:37 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 14:06 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-15 20:30 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:16 +0100
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 03:18 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 09:45 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 14:51 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 11:24 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 16:43 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 12:54 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 18:37 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 14:14 -0400
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-16 22:19 +0100
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-16 22:49 -0400
Re: double == double a.laforgia@gmail.com - 2016-10-17 01:53 -0700
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 19:04 +0200
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 20:17 +0100
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 23:11 +0200
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 22:46 +0100
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-18 18:55 +0200
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-18 18:52 +0100
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-20 15:03 +0200
True O-O [Was: double == double] Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-10-17 18:06 -0400
Re: True O-O Patrick Roemer <sangamon@netcologne.de> - 2016-10-18 18:32 +0200
Re: True O-O [Was: double == double] Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 22:09 -0400
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:58 -0400
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 18:58 +0200
Re: double == double 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid> - 2016-10-17 20:32 +0100
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-17 23:21 +0200
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:38 -0400
Re: double == double Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:47 -0400
Re: double == double Patrick Roemer <sangamon@netcologne.de> - 2016-10-20 15:01 +0200
csiph-web