Final = Bad
Michael Feathers goes public with the idea that "final" is just a bad idea:
Well... no.. not really. Here's the problem: When you use final pervasively, you make unit testing nearly impossible. Believe me, I know. I encounter enough teams who are in that situation. Have a class A which uses a class B that is final? Well, you'd better like B when you are testing A because it's coming along for the ride.
Extract an interface for B? Sure, if you own B. If you don't, you have to wrap it to supply a mock. And.. here's the kicker: if you are going to wrap B, well, what about security? All final does for a class is guarantee that the class itself won't be the point of access, but what about your wrapper? If you use the interface of the wrapper everywhere, again, because you want to test, the developers of B haven't made your software more secure, they've merely pushed the problem onto your plate: they've forced you to choose between testability and security. It's rather interesting to consider that perhaps we truly can have security, but only if we can't really be sure our software works.
The suggestion he has is the one that has been used in Smalltalk since the beginning: conventions that explain to developers which parts of a class' API might change in the future. What "final" does is attempt to lock the door before anyone's been in the house to look around. It assumes perfect knowledge about future usage, and that's a bad assumption.
Comments
[Isaac Gouy] May 21, 2006 13:41:31.000
Michael Feathers
[Gary Short] May 22, 2006 4:17:03.000
But I do mind System.DateTime being sealed as I want to add missing functionality that will allow me to add working days to a DateTime. As an aside, why is that even missing functionality? I mean, in business, how often to you want to add working days to a date to get delivery dates etc?!
Cheers,
Gary
http://www.garyshort.org/
[Isaac Gouy] May 22, 2006 11:53:49.000
"add working days to a DateTime"
Why should "working days" be a property of DateTime? Presumably working days varies from organisation to organisation, from country to country, and even from employee to employee. Wouldn't working days be a property of organisations, and countries, and people?
No one right answer
[ James Robertson] May 22, 2006 12:12:52.000
The larger point Gary is making, I think, is that there's no one right answer for a given class' shape. Why foreclose all possibility of extension by individual projects?
[Gary Short] May 23, 2006 3:55:27.259
Issac,
Excel, made by Microsoft, has built in functionality to add working days to a date. The DateTime class, made by Microsoft, does not. Argue what is right and what is wrong to your heart's content, but let's have a little consistency, and at the very least, don't seal the class so if I don't agree with you I can change it.
Cheers,
Gary
http://www.garyshort.org/
[Isaac Gouy] May 23, 2006 6:01:48.653
"Excel, made by Microsoft, has built in functionality to add working days to a date"
What are you talking about - in an Excel formula, in Excel VBA?
[Gary Short] May 23, 2006 11:42:00.378
Yes in a formula, which is analogous to an api like the .net library in my opinion, you can use NETWORKDAYS(start_date,end_date,holidays) to calculate the number of working days between start_date and end_date excluding holidays.
Cheers,
http://www.garyshort.org/
[Isaac Gouy] May 23, 2006 12:21:04.722
Gary, the Excel forumula NETWORKDAYS is like a function in functional programming, it is not like a method in OOP - there are no classes, no objects, no inheritance...
You can do the same thing in .Net (and it doesn't require any change to System.DateTime)
class AnalysisToolPak{ public static long NetWorkdays ( DateTime startDate, DateTime endDate, List[DateTime] holidays) { ... } }[] May 23, 2006 14:33:13.396
Yes and if the function did not exist in Excel you could write a VBA function to do it, all of which is totally irrelevent. The point is, that the function exists in one place and not in the other, and where it does not exist the class is sealed which prevents me from adding it myself.
[Isaac Gouy] May 23, 2006 15:37:42.044
Gary? "and where it does not exist the class is sealed which prevents me from adding it myself"
Exactly what prevents you from creating a class AnalysisToolPak with a static method NetWorkdays - the same as the Excel function?
[Isaac Gouy] May 25, 2006 2:34:35.098
Gary But I do mind System.DateTime being sealed
System.DateTime is not a class it's a struct - structs don't provide inheritance.
[Gary Short] May 25, 2006 4:14:02.572
Isaac,
Yes I could create a class that re-implements all the functionality of DateTime and then add my own method to add working days, but why should I have to? Re-implementing all that work does not seem like progress to me, nor does it jive well with the whole "OO brings reuse" deal.
And as for DateTime being a stuct and not a class and so does not provide inheritance, well that's only because Microsoft chose to blur the boundary. To me the difference is simple, a stuct is a lightweight class, having only knowlegde and no bahaviour. MS chose to add behaviour to the DateTime "class" and so if they want to treat it like a class then they should not be surprised when developers want to use it like a class.
The bottom line is, it should not be sealed, end of story.