4

In Android I can put only ArrayList of Parcelable objects in Intent:

Intent putParcelableArrayListExtra(String name, ArrayList<? extends Parcelable> value);

I can't put in there a List<? extends Parcelable>.

I have private method that get list of Parcelable objects from Intent (i.e. the method is used in its own class).

As I said there is always ArrayList in Intent. Should I declare return type of this method as ArrayList<>? Or List<>?

I think that ArrayList would be better because an ArrayList is also a List. But I often read that I should declare field type as most general possible type. I.e., Collection<> (or List<> if I need ordered collection) instead of ArrayList<>. But I don't see any reason to do so for this method return type.

  • 1
    The method is private. It doesn't really matter. Killian makes a good point in general but in this case the amount of refactoring you would have to do later on if you need to change your list implementation is practically nil. – Solomonoff's Secret Jun 16 '16 at 18:05
13

A declaration (whether a return type, an API comment or a contract) is a promise that you will deliver some good or perform some service. Declaring a specific return type is a greater promise than declaring a general type that is good enough for the caller, because it ties you down do a more specific action.

If that is really what you are doing and always will be what you are doing, then there's no problem with that. But if one day you want to refactor, extend or improve your program in a way that involves a new, better container type, you won't be able to, because client code would break if you switch to CoolNewList structures. Then you will say to yourself, "Gee, I wish I had listened to those wise people at StackExchange and made minimal promises instead of boasting with concrete types!", but it will be too late for you. Then you will start advising younger coders to keep their promises minimal, and so the cycle of life continues.

  • If this method is private ? – Leonid Semyonov Oct 10 '14 at 7:02
  • 1
    If it's private, you don't have to fear breaking client code, but you still have to fear breaking your own code. Fixing the caller is easier when you own the calling code yourself, but if you had returned List, you wouldn't have to fix the caller at all, so it's still better to declare List just to save type-related maintenance effort. Also, a utility method that returns List is way easier to understand than one that declares a fancy concrete type - a reader of the API will always think, "Hmm, I wonder if there's a gotcha that I ought to know about that DoublyLinkedSkipList..." – Kilian Foth Oct 10 '14 at 7:08
  • Do you know why the Intent method parameter type declared as ArrayList instead of List ? – Leonid Semyonov Oct 10 '14 at 7:18
  • It's partially a self-fulfilling prophecy. Experienced coders know that it's good to declare abstract types, so when they see someone declaring a concrete type, they assume that either the API developer is inexperienced, or that there is some reason why the specific type is named there. And unmentioned special conditions on the use of an API are very, very bad. Many if not most errors in complex systems arise because someone used a component that is almost, but not quite correct. – Kilian Foth Oct 10 '14 at 7:21
  • @LeonidSemyonov: It is hard to know why they did it without having been there when the API was written - given that all these methods exist since API level 1, it could be an oversight, performance considerations, convenience, or something else. – jhominal Oct 10 '14 at 7:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.