Still disagree.
I understand OO, to the put of having a degree in it, as well as other
external courses, sorry I don't add the little letters to my name, and I
know those who do, do it so that when they help out, people know they're
getting professional help, and that's a good thing. I am new to C# and what
it has to offer, and feel that being raw in your problems and why you think
it doesn't work is the best way to learn. I still don't like it, but please
don't make that a personal statement people, I don't like it, it's like you
saying that you don't like englishmen, and even though I am one, I wouldn't
get my back up about it.
It's not a perfect principle, and needs refinement, because it's not a
perfect world... in the real world, when developing large scale products,
you find that they are designed to a release point, then evolve as different
criteria arise. It's horrible to have to work on an project, then get told
from above that the application has to meet additional criteria. We should
then go back to the drawing board, and redesign it, then recode it. But if
you're limited to a serious time restraint and have deadlines to meet, you
need to work with what you have. Hey it's not ideal at all, actually it's
pretty aweful.
The point I'm making is that to restrict the developer to something that
they should not do because it's not proper, good, ethical, morally right, is
no feasible, for two main reasons that I see:
1. there are situations that arise where these ideals will need to be
broken...
2. so when these situations do arise, which you all must face, we have to
developer "neat" ways (!!!???) with working around these rules to produce,
in the end, the same result.
I'm all for good coding standards, and training people to work from good
design, and to develop great design principles, but it's not going to make
everyone who uses it write good neat code... Restricting someone who needs a
back door quick hack may suddenly think something like the following:
I need class G to access some value in class A, now they're not really
related at all, but for a quick hack I end up inheritting G from A, then
making the members protected and static. This obviously SUCKS for more
reasons than there are letters in this post, but it's valid syntax. So does
that mean the next OO is going to stop the user from doing this, because it
doesn't apply to the G IsA A principle... of course not.
Maybe one day I'll change my mind, but I'll stick with C++ for now thanks.
;o)
Are these the same clever people that said we'd only ever need a couple of
bytes for the year of a date? Sure it was essential stuff then, but over
time became rediculous as a concept.
So please, don't get offended that we don't live in the real world, and I
don't particularly like the pure OO programming lanuguage approach, even
though I like OO.
Anyway, thanks for the input, I've learnt a lot. Like the Logging example
was a bad one. ;o) Oh and I'm new to VB too...