I have to add my two cents. I agree with Scott only because the developer that applies the "final" keyword should understand why he's doing it. For an application, either open source or proprietary, that's centered around security to mark methods as final is smart.
Open source does not necessarily mean that it was written for ultimate freedom to modify or reuseability. For CAS it has allowed a way to build in quality through revision and strict control over new features. David On Tue, Apr 14, 2009 at 11:16 PM, Scott Battaglia <[email protected] > wrote: > > On Tue, Apr 14, 2009 at 10:55 PM, J. David Beutel <[email protected]>wrote: > >> I agree with you and your quote from the PDF. The onus is on the >> overriding code to work properly, not on the overridden code to be >> unbreakable. >> >> It's good to minimize scope and state, using private and even static >> methods where possible. But, "final" isn't as useful in open source, >> despite Bloch's Effective Java item 15. > > > Final is extremely useful in open source. It doesn't become less useful > because your source code is visible to all. If anything, it becomes more > useful. It ensures immutability when necessary as well as guarantees the > flow of critical paths within the code base. Combined with template methods > and extension points where you can inject your own class, it makes it clear > how the code is expected to be used. It reduces the chances of accidentally > overriding critical code, or calling it in an inappropriate order. > Extending behavior with template methods and plugins or using the delegation > pattern makes it clear to both the developer and the CAS team what is going > on if help is requested. It also creates a dialog between the developer > community and the community-at-large to ensure that we are collectively > doing the same/correct thing > > In addition, usage of the final keyword turns a lot of former runtime > errors into compile-time errors which makes debugging easier. > > When additional use cases are identified we re-evaluate the usage of final, > as well as whether appropriate extension points should be created instead. > This has served us well in balancing the needs of the community and ensuring > that we can address support concerns. > > At this point, we have no plans to discontinue our judicious usage of > "final" to ensure the quality and integrity of the code base and > deployments. > > Thanks > -Scott > > >> >> Cheers, >> 11011011 >> >> >> >> Björn Weinbrenner wrote: >> >>> Hello! >>> >>> I found a lot of final methods in the code of the cas java client and I'm >>> not very happy about it. I extended CAS in a few -and for me very useful- >>> ways, but sometimes there were dirty workarounds necessary (badest: copy of >>> the original class) to extend your classes. >>> >>> I found in the wiki ( >>> http://www.ja-sig.org/wiki/display/CAS/Code+Conventions) a section about >>> the use of final: >>> Use of the final keyword. >>> >>> We use the keyword "final" wherever we can, because it is probably a good >>> idea. >>> >>> This section is linked to a pdf which I read very carefully: >>> http://www.oreilly.com/catalog/hardcorejv/chapter/ch02.pdf >>> >>> In this PDF you find the following section: >>> "You should never make a method final unless it must be final. When in >>> doubt, leave >>> the final keyword off a method. After all, you never know the kinds of >>> variations the >>> users of your class may come up with." >>> >>> Thus I don't understate your explanation. I would like your code having a >>> minimum of final methods. >>> >>> After all I like your project and the product cas very much. >>> >>> Regards >>> Björn >>> >>> >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
