PDA

View Full Version : Final


maskedMan
04-16-2009, 05:44 PM
Here's something that I've been pondering for some time:

Of what practical use is it to declare your functions / classes 'final'?


final function foo():void{
trace("Can't override me!");
}


Don't you ideally want to make your code flexible and extensible? What sorts of situations would arise that require you to declare something off-limits for extention?

ASWC
04-16-2009, 06:51 PM
The obvious case for me is to avoid errors. Like a typical method would return a typical formatted number and this formatting is expected, then if you override the function and change the type of formatting the classes using this method to get data would break because the formatting is not correct anymore. See what I mean? Or maybe simpler you have a videoprovider class that gives you a ... video and you use that with a videomanager class the is expecting a video, now you override everything in your videoprovider class and pass a jpg instead, obviously the videomanager won't work. So by making the videoprovider final you can ensure that the object passed by the videoprovider will be of the correct type.

maskedMan
04-16-2009, 07:41 PM
So if I understand correctly, it's good to use final to prevent people from mucking up a function that returns a generic object or an array, two dynamic and unpredictable objects, when the object that requires the input from that function expects the generic object or array to be formatted in a specific way?

Isn't that what typed objects are for, though? Or if you need to pass an array why not use a typed collection class that implements an interface?

yell0wdart
04-16-2009, 08:11 PM
That's the most common reason I've seen (that ASWC) mentioned. It's also worth mentioning often times, these types of circumstances can be gotten around by applying the Dependency Inversion Principle (http://en.wikipedia.org/wiki/Dependency_inversion_principle) (ie: programming to abstractions rather than concrete classes). When you can't get away with this, though, final is a fantastic way of encapsulating functionality that you *know* will not be changing structurally.

ASWC
04-16-2009, 08:46 PM
it's always easier to give simple examples but now think about a 3D object data with coordinates, colors, whatever you might think that is generated and passed by a class. Now such object can be quite complex and it's managed by a class that knows just how to manage these object. Now you could extend the class that generate these object and add some properties and override some methods if you know exactly how the manager class will handle all this, but if you don't then better would be to not override some sensitive methods, or properties or the whole class itself in this case final would prevent you from doing that and running into troubles.

Assertnfailure
04-16-2009, 10:35 PM
Less is more. Classes are easier to use and understand when there is less exposure. Likewise, classes are harder to break when less implementation can be overridden.

In the case of abstract classes, if I see a protected method, I can draw a couple of assumptions about it. Is it meant to be overridden? Is it meant to be called manually? Of course, a final protected method isn't meant to be called for any purpose other than to execute its implementation.

runawayprisoner
04-16-2009, 10:59 PM
Well, practically, you declare a function/method final when you see no benefit whatsoever in mutating or modifying it. For instance, modifying a "get" or a "set" function is... extremely pointless. If you need new data types, you can make new "get" and "set" functions for those. Also modifying "get" and "set" might... give ground to some silly privacy errors to occur.

In the same context, modifying functions that calculate something is also very pointless unless that same function is called multiple times within the class, and you would like to change the output of that function to change the functionality of some other functions. But I find that it's best to leave the calculating function alone in that case because there is no way to tell what kind of disaster it can bring. It might be able to change the output for some other functions, while the rest might be severely broken somewhere. I think that if you need to change the functionality of a certain function, you may well try to override it and write new calculating functions as necessary.

Now, last but not least, I might also put "final" on some of my functions in sensitive classes so that I don't get bugged by my colleagues whenever they run into an "implicit coercion of type"... error, which happens a whole lot. Basically what AWSC mentioned. We can cast the type, yes, but if it's not the same kind of inheritance, or the new function uses a whole new kind of abstract class, then there are more troubles to come.

maskedMan
04-17-2009, 09:54 PM
Certainly food for thought. I can definitely say though, that I've had instances where overriding set methods has been handy in UI subclasses but in general I see what you mean.

-Ev-
04-19-2009, 06:32 PM
I declare all my static classes as final. There's nothing to inherit or override, so the compiler should tell people not to even try.

Flash Gordon
05-16-2009, 09:19 AM
Well, practically, you declare a function/method final when you see no benefit whatsoever in mutating or modifying it. For instance, modifying a "get" or a "set" function is... extremely pointless. If you need new data types, you can make new "get" and "set" functions for those. Also modifying "get" and "set" might... give ground to some silly privacy errors to occur.

oh....the essence of the Flex framework!

// UIComponent
override public function set x(value:Number):void
{
if (super.x == value)
return;

super.x = value;

invalidateProperties();

dispatchEvent(new Event("xChanged"));
}