3

In the Android support libraries here the destroyItem and instantiateItem functions throw an exception if they aren't overriden:

175        throw new UnsupportedOperationException(
176                "Required method instantiateItem was not overridden");

Why wouldn't the developers just make the functions abstract? Wouldn't that be the more correct way of ensuring the functions are overridden, from an OOP perspective?

1 Answer 1

4

The makers if of the adapter most likely do not want to force the developers extending the class to implement said methods unless you really need them.

You can extend the class without the need to use the mentioned methods, if they were declared abstract, you would have to write code you would never use, or throw the exception yourself.

Go ahead and check YAGNI.

3
  • Good point - I didn't think of that. It's weird though in the class I linked to (PagerAdapter) because it fulfills a fairly specific use case (it doesn't seem like there would be any situation where those functions wouldn't be used), but maybe there's a corner case I'm not thinking of. Commented Nov 4, 2015 at 9:13
  • @MattLyons: Those functions are marked Deprecated, with different overloads being preferred to be used. New code, including new derived Adapters, shouldn't be using those functions anyway. Commented Nov 4, 2015 at 9:21
  • 1
    I think Bart's comment raises a very valid point. You DO need to override these as the documentation states so the question of why they are not abstract cannot be answered by saying 'you are not forced to override them'! Making these methods throw an exception would be a prime strategy to move these towards deprecation: you CAN have them, but new code SHOULD NOT have them. I think that's a better answer here...
    – JDT
    Commented Nov 4, 2015 at 9:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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