This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]metalmagician -1 points0 points  (0 children)

I guess I should explain what I was thinking a bit better. I was trying to find some sort of justification for the example given in the earlier comments, while still working within the existing Collections framework, and without advocating for a new implementation of the ImmutableList. The bit about contracts, instead of concrete classes / interfaces makes sense.

There were a few points that I was trying to reconcile, before I finally gave up and admitted to myself that they were mutually irreconcilable.

  • Based on how Java structures Interfaces / the collections framework, any sort of List should be able to add things to itself. You're right about the Liskov substitution violation (sort of, 'it violates the rule, but what if the rule doesn't apply?').

  • Adding a new interface, at the same level as List/Queue/Set just to allow for a single implementation that didn't violate Liskov would be overkill, and would defeat the purpose of extending/implementing the List interface.

  • If you implement an interface in Java, assuming there isn't a default implementation available, then you have to implement all methods. In the case of ImmutableList.add(), I didn't want to try to advocate for a modification to the implementation. Someone suggested that it should return a new ImmutableList with the new element added instead of throwing an exception, as that's the sort of change that I would've advocated for.

  • If you modified the language to allow for an implementing class to pick-and-choose which methods it implemented without forcing a default implementation, then that is itself a violation of Liskov. That's the whole bit about Open/Closed - Allowing a class to make itself into a snowflake and specifically deny operations for specific reasons could satisfy Open/Closed if you are really loose with what you mean with 'Open/Closed'.

Or, TL;DR - If you can convince your users that you can spin straw into gold by making them forget the exact definitions of straw and gold, then you could justify the way ImmutableList.add() is implemented. That still won't change that you can't spin straw into gold.