Closed luceos closed 7 years ago
Hi @Luceos
The reason I use final, is to prevent anyone implementing this library, from extending these classes. This sounds a bit harsh, but it's actually a good practice in my opinion. Please allow me to explain.
If you have multiple people implementing this library, you can't change the method signature of a public method, without having a backwards breaking change. Therefor you need to upgrade to a new major version according to semantic versioning.
If I open my classes up for extension, the internals of this class have the same responsibility of a public method. If I choose to refactor anything around the public methods, I might break use cases that I haven't even thought of.
Furthermore, I think this also encourages making pull requests to the library for behavior that should be in here.
While some functionality is not common enough to be in a library, you can always use the decorator pattern to 'wrap' the client, while still complying to the interface that the services classes require.
Is there a use case that you are missing that would be beneficial to add in this library? I would love to hear that from you.
If you have any further questions or suggestions, please let me know :)
Makes sense and thanks for clarifying!
Hi @dennisdegreef ,
Thanks for writing this client, was looking at writing my own, but that seems to be unnecessary. Something that blew my mind though is your relentless use of the
final
keyword for classes. I can imagine you want to do so for aesthetic reasons, but it would make extending your classes (eg enriching them with other functionality) a lot easier if they were not final.Can you shed some light on this? Because imo declaring any class final in open source work is very obstructing.
Hope to hear from you.