POV-Ray : Newsgroups : povray.off-topic : Learning C# : Re: Learning C# Server Time
29 Jul 2024 04:19:21 EDT (-0400)
  Re: Learning C#  
From: Darren New
Date: 29 Sep 2012 13:32:20
Message: <506730a4$1@news.povray.org>
On 9/29/2012 3:27, Orchid Win7 v1 wrote:
> Regardless, C# turns this backwards. In C#, by default you /cannot/ override
> anything, unless you explicitly turn it on by writing "virtual". Meaning
> that if the author of some class didn't foresee the potential need to
> subclass it, you may not be able to override the necessary methods.

In practice, this is generally not a problem. If you're not thinking of code 
at the level of overriding virtual methods, it's usually impossible to 
override a method correctly, unless you're just doing something like adding 
logging that the method got called. (At which point, how do you get your 
custom class into the places where it's supposed to be, if others are 
instantiating the wrong class?)

> Apparently it is "very hard" to design a class in such a way that it can be
> subclassed correctly. So you should only allow this possibility where a
> class has been explicitly designed with the intention of being subclassed
> later. In all other cases, you should disable subclassing, because if you
> didn't design for it, it won't work anyway.

While this is excessive, it's probably good advice for people who haven't 
done a fair amount of work on such projects. Sealing the class is probably a 
bit much, but not declaring things virtual that you don't expect a subclass 
will want to override is not a bad thing.

> All of which strikes me as a little baffling. I mean, I know that
> inheritance is overused and collaboration is underused. But this just seems
> excessive!

It is. But then again, absolute advice given in a beginner's book is usually 
excessive. You develop the good habit, *then* you learn from experience 
where the right place to break the habit is.

> Then again, this is from the same book that explains how to write
> destructors (i.e., "don't") before explaining how to write methods with
> named arguments. The former is an obscure and very dangerous feature which
> you should never use, under any circumstances, ever. The latter is a pretty
> simple and common feature. Really, the order of presentation here seems
> rather strange.

Sounds like he wanted to mention destructors along with constructors, and 
since he had nothing to say about them besides "don't", he had no other good 
place to put them.

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.