It depends.  I've done that, but not always.  The best practice is to declare
a variable to be the most general type suitable to its purpose.  Writer might
lack a method that, say, PrintWriter has, and thus you'd not declare a
variable Writer if you needed that extra method.

If you don't need the specific behavior, then you absolutely should declare
the variable to be of the more general type.

You might need "c" to be a list - ordered, permissive of duplicates and
index-accessible.

Upcast.  The technical name is a "widening reference conversion".
<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.5>

Joshua Bloch has a tip about this in his seminal /Effective Java/.

On Nov 7, 6:09 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

It's an implicit widening reference conversion (5.1.5):

--\--
A widening reference conversion exists from any type S to any type T,
provided S is a subtype (?4.10) of T.

Widening reference conversions never require a special action at run
time and therefore never throw an exception at run time. They consist
simply in regarding a reference as having some other type in a manner
that can be proved correct at compile time.

See ?8 for the detailed specifications for classes, ?9 for interfaces,
and ?10 for arrays.
--/--

The type of the variable carries around some documentation of what
promises the code expects from the referenced object.  In the case of
List<T>, I try to use the most general interface I can; if I need
get(int) but don't care much about the run time, then obviously it's
got to be a List<T> since indexed get is not provided by
Collection<T>, but if all I'm doing is iterating over the contents
then Iterable<T> might suffice (being slightly more general than
Collection<T>).  If the algorithm I'm writing relies on O(1) seek
time, then I'd declare it as ArrayList (in the absence of a
"ConstantTimeSeekingList" interface :-).

With the stream decorator patterns I categorize things into sources
(which I pass around as Reader or InputStream instances) and
processors (which I pass around very little, and declare as their
concrete type).  Source streams provide the basic stream, and should
be pretty much interchanable, but processors include things like
BufferedReader that provide features not available from the basic
Stream/Reader interfaces.

-O

On Wed, 07 Nov 2007 18:09:22 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

because List has ordering/random indexed access methods missing from
Collection, e.g. set(int index, E element);

If you did not need the random indexed access, Collection would be
appropriate. The theory is you use the interface/class with the
smallest number of methods that still lets you get the job done.

On Wed, 07 Nov 2007 18:09:22 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

Every Dalmatian is automatically a Dog.  You can use a Dog reference
to a Dalmatian, but you can only use the Dog methods. This is
explained in every basic Java text book.  Someone else might point you
to the lawyerese version of it in the JLS.

see http://mindprod.com/jgloss/dalmatian.html

On Wed, 07 Nov 2007 18:09:22 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

Because when you use a FileWriter, BufferedOutputStream,
BufferedOutputStream, etc you often need access to all the specific
methods.

For example you would not write:

Writer caw = new CharArrayWriter(1000);

because you could not write:

char[] results =  caw.toCharArray();

The catch is the various flavours of Writers are not quite as
interchangeable as Collections or Lists. The interfaces they implement
are primarily documentation to group similar classes.

On Wed, 07 Nov 2007 18:09:22 -0800, Knute Johnson
<nospam@rabbitbrush.frazmtn.com> wrote, quoted or indirectly quoted
someone who said :

see http://mindprod.com/jgloss/upcasting.html
http://mindprod.com/jgloss/downcasting.html
http://mindprod.com/jgloss/cast.html

...

...

It is assignment conversion, mentioned in the description of the simple
assignment operator at
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.26.1

"A compile-time error occurs if the type of the right-hand operand
cannot be converted to the type of the variable by assignment conversion
(§5.2)."

Assignment conversion, defined in section 5.2, can be any of:

# an identity conversion (§5.1.1)
# a widening primitive conversion (§5.1.2)
# a widening reference conversion (§5.1.5)
# a boxing conversion (§5.1.7) optionally followed by a widening
reference conversion
# an unboxing conversion (§5.1.8) optionally followed by a widening
primitive conversion.

In this particular case, it is a widening reference conversion.

Patricia

A bit off the point, but FileWriter and FileReader are evil and/or useless,
since they don't allow an encoding to be specified.  The proper way to
create a Writer that writes to files is

   new OutputStreamWriter(new FileOutputStream(file), encoding)

I didn't read the earlier discussion so may be going over old ground

One really cool thing about interface polymorphism is that it allows you
to write components that provide clients with an abstraction, leaving
room in the brain for the things that really matter.

A component with a published interface of (say)

public List foo() tells clients that they are getting a List and should
only do List like things with it. They probably have more important
things to worry about than your implementation of the component

Internally to foo() of course I may decide to use an ArrayList to do my
work then I might use List l = new ArrayList(). Why might I do this ?

Well if, in the future some fancy new component comes along that can do
List type things in a much more efficient
way I might like to change my internal implementation to use this new
component, I certainly don't want to change the published interface as
this might break all sorts of things.

Of course I could still do ArrayList l = new ArrayList() but then when I
wanted to change I'd need to be sure that all internal references to l
were capable of handling the new type,
Of course a long as the new wizzy list thingy still implemented List the
published interface would remain unchanged.

You ask about Writer fw = new FileWriter

Well, same reason really, what happens when you decide to change your
implementation to use the new VeryFancyTCPNetworkStorageWriter class,
all your clients care about is that now they can write much faster
and that they don't need such a big disk (or whatever).
They certainly don't want to hunt down every reference to your component
and change things because you have decided to change the internal
implementation.

Anyway, just my 3 groats worth.

...

ArrayList seems an unfortunate choice of implementing class, given the
code only needs the common features of Collection. ArrayList makes some
insertions and removals expensive for the sake of efficient indexed
access. Why pay that cost if you don't need indexed access?

Collection does not make it clear whether duplicates are allowed or not,
so I would usually use either List or Set instead.

Patricia