Re: final methods and classes
Rze=C5=BAnik wrote:
I am not sure whether we understand each other. Let me reiterate: you
said that one should NOT predict, with which I agree. But you clearly
do not want to see that 'final' is one endless bag of predictions.
Every 'final' you put in your code cries: I PREDICT THAT THIS METHOD/
CLASS HERE IS WRITTEN IN STONE. While sometimes predictions like these
may be valid, more often than not they aren't.
Your point here is incorrect. Declaring a class 'final' is not a
prediction, it's a constraint. You are not predicting that "this
method / class is written in stone" with 'final'. You are forcing it
to be. No prediction involved, just control. I advocate dictating
the use, not predicting it.
I am declaring rubbish not his reasoning per se, but his reasoning as
you described it - that may be two different things. Anyway, there is
I described it thus:
Every time you omit 'final' in a class declaration you should consider
carefully. Read the item in /Effective Java/ referenced upthread for a
thorough explanation of why to prefer non-heritability.
In other words, "Read the book. See for yourself."
What part do you disagree with, that you should consider carefully, or
with the reasoning expressed in the book to which I referred?
no VALID argument against inheritance in OO language. One may argue
No one is arguing against inheritance, just its abuse. Read the
book. Decide for yourself.
that inheritance should be thought out and thoroughly reviewed but one
Ummm, yeah-ah.
cannot state that it should be abandoned as it is the only way to make
sure that OO system is opened for future modifications while being, at
Straw man, straw man, straw man. I also am not arguing against
inheritance, or for its abandonment, only against its abuse.
the same time, closed so that it is able to execute. The more final
you use, the more closed your class hierarchy becomes - which is
almost always 'the bad thing'.
I am simply saying that one should design and document for inheritance
(of concrete classes), or else prohibit it, in line with and for the
reasons stated in /Effective Java/.
If you don't design a class to be heritable but allow it to be, then
you have problems. You cannot use the circular argument that a
recommended practice for object-oriented programming violates the
principles of O-O without demonstrating that it does, in fact, do so.
So let's try again - drop the straw man and circular arguments.
--
Lew