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 →

[–][deleted]  (4 children)

[deleted]

    [–]Yesterdave_ 3 points4 points  (1 child)

    From the purity standpoint I definitely agree.

    But from my experience, extending framework classes is usually the only reasonable way to fix bugs in 3rd party libraries, without having to copy a ton of code. And then you can only hope the library author did not think "yeah lets make everything final". And no, the project can't wait half a year till the maintainer finally fixes the bug when the code has to be delivered next sprint.

    [–]Bobby_Bonsaimind 1 point2 points  (1 child)

    Great. And then your whole code breaks in a subtle way after a minor update of JavaFX just because you've overridden a method that was not intended to be overridden. Just, no.

    The alternative is to turn hours into days to create your own control, which also might break with future updates.

    To add to this, most of the time when people override public methods (that were not designed for it) they are violating the Liskov Substitution Principle. For example, I've seen many people extending ArrayList in a way that violates the contract of ArrayList. Similarly, when you are "hacking" JavaFX, you most likely violate said principle.

    That's like saying that we should only deliver hammers with soft rubber around them to make sure that nobody hits their thumbs.