Yes, and when that's part of a framework, future users of the framework can be pushed into a corner because the framework designer e.g. did not intend/foresee a new security approach that doesn't use username and password but 1 string or 3 strings.
When using 'final' on a class you inherently intend to not be future-proof, whether you realize it or not.
Being future proof should be a conscious decision (because its cost and risks are non-negligible), not the developer's to make.
To me, it's comparable to having a const member function/parameter/local that guarantees that my code does what I want it to do.
Unless I declare a public class final, It's harder for me to guarantee the working of the framework (cf. fragile base class). If I want you to extend behavior, I'll make you inject an interface you can implement.
The middle ground is I give you an abstract base class to extend. Consciously.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Yes, and when that's part of a framework, future users of the framework can be pushed into a corner because the framework designer e.g. did not intend/foresee a new security approach that doesn't use username and password but 1 string or 3 strings.
When using 'final' on a class you inherently intend to not be future-proof, whether you realize it or not.
You are right. The user is pushed into a corner.
Being future proof should be a conscious decision (because its cost and risks are non-negligible), not the developer's to make.
To me, it's comparable to having a
constmember function/parameter/local that guarantees that my code does what I want it to do.Unless I declare a public class
final, It's harder for me to guarantee the working of the framework (cf. fragile base class). If I want you to extend behavior, I'll make you inject an interface you can implement.The middle ground is I give you an abstract base class to extend. Consciously.