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 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.
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 time exactly which class the created method will be. But why would that
be the case here? THAT is what needs to be explained.
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
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.
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.
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.
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.
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
