Am 03.06.2013 10:11, schrieb deadalnix:
On Monday, 3 June 2013 at 07:30:56 UTC, Kapps wrote:
On Monday, 3 June 2013 at 07:06:05 UTC, Manu wrote:
There are functions that
the author intended to be overridden, and functions that have no
business
being overridden, that the author probably never imagined anyone would
override.
What if someone does come along and override one of these, and it was
never
designed to work under that circumstance in the first place?
At very least, it will have never been tested. That's not a very
robust API
offering if you ask me.

This is something just as important as the performance issues. Most of
the time people will leave functions to simply use whatever the
default is for virtual/final. If it's final, this works fairly well.
The author hasn't put in the effort to decide how to handle people
overriding their function. But with virtual by default, you don't know
if the author actually considered that people will be overriding the
function or if it's simply that they didn't bother specifying. I know
the vast majority of my code is virtual, simply because I didn't
specify the 'final' keyword 500 times, and didn't think about that I'd
need to do it. The resulting code is unsafe because I didn't consider
those functions actually being overridden.


The whole concept of OOP revolve around the fact that a given class and
users of the given class don't need to know about its subclasses
(Liskov's substitution principle). It is subclass's responsibility to
decide what it override or not, not the upper class to decide what is
overriden by subclasses.

If you want to create a class with customizable parts, pass parameters
to the constructor. This isn't OOP what OOP is about.

The performance concern is only here because things has been smashed
together in a inconsequent way (as it is often done in D). In Java for
instance, only overriden function are actually virtual. Everything else
is finalized at link time. Which is great because you are able to
override everything when testing to create mock for instance, while
keeping good performance when actually running the application.

While this is true for most OO languages, you should not forget the "Fragile base class" principle.

But this applies to both cases, regardless what is defined by default.

--
Paulo

Reply via email to