Indicator Veritatis wrote:
> You question the 'naturalness' of his desire to use 'new', but you don't
> seem to notice: you have merely moved the question, not answered it. Of
> course it
Actually, I did answer it.
> is 'unnatural' to call 'new' on an abstract class, but he was asking why
> it was made abstract in the first place. You did not address this. Nor does
> the Google documentation of the class.
Actually, I did address it.
>
> All you did was move the question to "why is calling a factory method more
> 'natural'?" After all, factory methods are for when you do NOT know ahead
> of
>
That is only part of what I did.
> time exactly which class the created method will be. But why would that be
> the case here? THAT is what needs to be explained.
>
I explained that it might be necessary, and that that is the usual reason
for abstract classes with factory methods in Java.
I speculated as to what factors would make such a decision attractive to
the API designer.
>
> Nor is it clear why you think there should be no obvious implementors of a
> class named 'Uri'. One obvious implementation of a class with such a name
>
I didn't say I think there should be no obvious implementors of a class
named 'Uri'.
I don't actually think that.
That could explain why it's not obvious why I think that.
> would be 1) Constructor takes string, returns (opaque?) integer handle for
> uri 2) methods for opening, closing, fetching resource at uri given by
> handle. But this is not the way Google did it; the Uri class instead has a
> noticeably more restricted scope. It does not provide methods for opening a
> Uri and fetching resources. Instead, the main methods provided are for
> analyzing the Uri string itself, breaking it down into port, authority (if
> any), query string etc. Other objects are then responsible for fetching.
>
That's nice.
>
> What benefit they got from doing it this way is far from clear, especially
> since they are now recommending use of java.net for external HTTP access
> for recent versions of Java, using android.net mainly for the internal
> Uris used for Content Providers.
>
Well, we can but speculate, as I did.
>
> As for using the Wikipedia entry, I have been often disappointed by
> Wikipedia entries on OOD topics before. This time also, since they put the
> reader through an alleged Java example of the Factory method (complex
> numbers), and then admit that strictly speaking, it is not even an example
> of the pattern. This is NO help to the learner, and little help to the
> seasoned programmer.
>
I found it helpful, both as a learner and as a seasoned programmer. I'm
sorry you found it less useful.
>
> Finally, it is ironic that you observe (correct though that is), that use
> of factory methods is "prevalent throughout the Java API". For java.net.URI
> is NOT abstract, but android.net.Uri IS abstract. The similarity of these
> names is probably a large part of why the OP expected both to be concrete.
> Both claim, after all, to do roughly the same thing: represent a URI (one
> immutable, the other mutable). The differences in the API alone do not
> really explain why they made it abstract.
>
>
Nor do my speculations. They only provide pointers to the type of reasoning
involved in creating factory methods.
I guess you're angry that I didn't break out my crystal ball and read the
Android team's mind. I do apologize for that.
--
Lew
>
> bob wrote:
>>
>>> Can someone help me understand why the android.net.Uri class is abstract?
>>>
>>>
>> You got the "what", now for the "why".
>>
>>
>>> Naturally, I want to do something like this:
>>>
>>> I question the naturalness of that desire.
>>
>>
>>> Uri uri = new Uri("http://www.example.com/file.mp4";);
>>>
>>>
>> It's more natural, some would say, to use a factory method. (Google "Java
>> factory method"
>> and you'll find, e.g.,
>> http://en.wikipedia.org/wiki/Factory_method_pattern#Java, complete
>> with reference to Josh Bloch's advice on the matter.)
>>
>> It's entirely unnatural to want to call a constructor on an abstract
>> class. Such a class with
>> no obvious implementors is a signal that it has a factory method. This is
>> quite prevalent
>> in the Java API.
>>
>> The "why" is to save the client from messy and irrelevant details of the
>> implementation.
>> You shouldn't have to decide which particular flavor of 'Uri' to
>> instantiate, especially if the
>> thing is tricky (e.g., has to support an ever-expanding list of
>> protocols). Let the factory
>> manufacture you one and you save all that headache.
>>
>> Study up on the reasons to prefer a factory method, and when not to.
>>
>> --
>> Lew
>>
>>
>>
>>
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
