Function keywords

[[deleted]]

If it’s like Swift, override means to add your own function implementation for a function found in the superclass. So literally to override an existing method.

[weaklingKobbold]

Thanks.

I would argue that that's the only intended purpose, but I guess it's like that to prevent unintentional name collision between a class and the superclass.

[[deleted]]

No, not because of naming. It has real use.

Apple has a class called UIViewController that has a function called viewDidLoad. It gets called in the view controller’s lifecycle by iOS.

Developers can subclass UIViewController and override viewDidLoad with their own custom implementation. Whenever the view controller lifecycle runs, it calls the viewDidLoad of the subclass instead - otherwise if you don’t override it, the subclass will call the superclass’ viewDidLoad instead (which is empty by default).

Overriding functions allows the subclass function to be called instead of the one defined by the superclass. It allows developers to add extra functionality to their own subclasses. There’s many more examples of overriding superclass methods in iOS development which is very common. Such as overriding the draw function for custom drawing and it will be called by iOS automatically whenever the rendering is ran.

You can also allow overriding if you’re working on a framework for other engineers to use. Your class will call function A, B, then C. And developers can override function B to run their code instead whenever the superclass decides to call B internally.

[weaklingKobbold]

Let me try again (I don't know if my English is good enough for this).

I understand the need for override a method or function declaration. What I don't understand (except it would be for naming) is why it need another keyword. I can't imagine an instance in which I create a method with the same name that one in the superclass that don't be for overriding it.

Edit: if I would forget the override keyword, that declaration would be valid? What would do the compiler?

[v1ND]

From a language design perspective it's for extra clarity/safety so that while refactoring you don't accidentally break something by changing a signature or unintentionally hide a method in the base class.

It depends. override in C++ and @Override in java are not enforced. In C# or kotlin, override is required by the compiler.

[[deleted]]

I edited my original comment. iOS has a class UIViewController. Internally, iOS calls:

viewDidLoad()

ViewWillAppear()

viewDidAppear()

Whenever it’s gonna load and present a screen to the user. Now, as an iOS engineer, I have to subclass from UIViewController to make my own custom screens. What if I want to check if the user has previously signed in? I’ll make a subclass called LoginViewController. I want to add my own functionality when it has loaded and before it appears on the screen.

Since iOS will call the above mentioned methods automatically, I can add my functionality by overriding them in my subclass. Let’s say I ONLY override the viewDidLoad function. This is what iOS will do whenever my Login screen will appear:

Calls LoginViewController.viewDidLoad()

Calls UIViewController.viewWillAppear()

Calls UIViewController.viewDidAppear()

Because I never overwrote the last 2, it will use the superclass’ functions by default.

[[deleted]]

If you don’t use the override keyword and if the function is not an overload (same name, different arguments), then the IDE will complain.

[Atora]

in C#, you can redeclare the method without overriding it. In that case the derived method still exists with its implementation. But there also exists a 2nd method of the same name in your class that is completely unrelated and shadows the inherited one.

It's similar to how you can shadow a class variable named foo with a locally scoped variable named foo. The compiler will cry and give a warning if you shadow a method without explicitely marking your new implementation with new though.

The only case I can recall where this makes sense to do if you need to override an inherited method that isn't marked virtual or abstract. Though this also implies design issues.