|
I was thinking about your problem with the collection a few days ago when I was reading about extension methods. Have you tried using those?
|
|
|
|
|
Of course, but they solve a different problem.
|
|
|
|
|
You could go back and change them to be virtual if it turns out you need them to be, right? What's so bad about that?
Having uselessly virtual methods around can only degrade performance and has no benefits..
But I don't determine what gets to be "best practice"
|
|
|
|
|
harold aptroot wrote: change them to be virtual
Only if you have the source code -- I'd love to change built-in .net classes to have virtual members.
|
|
|
|
|
Yes, so would I
But, if you're writing something, you have the source code..
And if you're writing a library, well, all libraries suck anyway  (ok then make some things virtual, but that doesn't mean everything should be virtual Just Because)
|
|
|
|
|
I prefer to err on the side of usability (extensability etc.) and let the hardware engineers worry about improving performance. 
|
|
|
|
|
PIEBALDconsult wrote: I'd love to change built-in .net classes to have virtual members
For some reason this makes me think you've been coding an ASP.NET porn site.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
If I could devise a better mouse trap, I might; but for now I'll just enjoy the exsting mouse traps. 
|
|
|
|
|
If you make it virtual now what happens later on (days, months, years) when you want to modify it? You look at the method, see it's virtual and ask yourself "Has anything overridden this method? If so will this change break those child classes?".
If you make everything virtual automatically then the only way to answer that question is to go through your code base and look. If you only make methods virtual when they need to be then you already know the answer: "Nothing has overridden this because it can't be overridden".
Also, later on it's trivial to add the modifier but difficult to add it for the same reason. Adding it can't break any other code, removing it can.
The same can be said about any question involving code security. In general the safest bet is to go with the most restrictive permissions you can and then loosen them up as needed. Loosening permissions is easy, tightening them is hard.
|
|
|
|
|
I find none of that compelling.
Jimmanuel wrote: Loosening permissions is easy, tightening them is hard.
A consumer of your class is far more likely to want you to loosen than tighten; so make it as loose as practical from the start.
Jimmanuel wrote: will this change break those child classes?".
Let the buyer beware. I'm not responsible for anyone using my code, and if they don't like it, they can write their own.
What's worse is frameworks that are unusable because things are too tight.
|
|
|
|
|
We're not developing frameworks, though. If I break somebody else's code then I've caused problems of unknown severity somewhere else in our application, which is a large distributed enterprise app. If a feature stops working it's not the customer that comes bitching to me; it's the guy sitting next to me, possibly my boss, that shows up asking me why I broke their code. Because of that I try to do everything that I can to ensure that I can't break their code.
|
|
|
|
|
That still sounds like they did something wrong. And you wouldn't discover that unless you demonstrate to them why they shouldn't do what they're doing in such a way that they can't ignore.
Ideally, within the organization, there is someone with a view of the larger picture.
|
|
|
|
|
PIEBALDconsult wrote: That still sounds like they did something wrong
Often times that's true, but usually when it is that developer isn't around anymore to explain themselves and I get to fix it for them.
PIEBALDconsult wrote: Ideally, within the organization, there is someone with a view of the larger picture
and therein lies one of the problems with our organization
|
|
|
|
|
That's much of why I enjoyed being a team of one on my last job.
|
|
|
|
|
Jimmanuel wrote: Adding it can't break any other code,
I don't want to bother to delve into it now, but as I recall, in C# changing the virtual-ness of a base class' method in either direction will mean you have to alter the override-ness or hide-ness of an overriding or hiding method of a derived class.
Yeach  , I should have bothered to delve; nothing to see here, move along.
modified on Tuesday, December 8, 2009 10:52 PM
|
|
|
|
|
So if you have a non virtual method in a base and a "new" method in a child that hides it, you have to change the hiding child method to an override if you change the base method to be virtual?
If that's true then that's one more reason that I don't like hiding methods with "new". Following along the same lines as before, if a child has the need to hide a method in a base class I'd call that grounds to make the thing virtual in the first place instead of just hiding it.
|
|
|
|
|
Jimmanuel wrote: you have to change the hiding child method
Dang, I thought that was the case, but a little experiment seems to have proved me wrong (again).
I know some time in the last few weeks a thread dealing with something like that came up, in which you had to use new with either override or virtual. I'll try to find the thread.
Edit: I didn't find it.
Jimmanuel wrote: I don't like hiding methods with "new".
Absolutely.
modified on Tuesday, December 8, 2009 10:43 PM
|
|
|
|
|
A class needs to be designed for inheritance. If you just make stuff virtual, you end up with the fragile base class problem[^].
Composition (and encapsulation) is way better than inheritance.
If the base class calls any of its own virtual methods, this must be documented! And any future change to these internal calls must be considered a breaking API change. See http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=3[^] for an example.
Usually, I just make my classes sealed. Extensibility is hard work, just slapping a few virtual modifiers on your methods without thinking will only cause trouble in the long run.
|
|
|
|
|
Daniel Grunwald wrote: A class needs to be designed for inheritance
That means the methods should be virtual. Without virtual methods there's no polymorphism. Without polymorphism there's very little reason for inheritance.
Daniel Grunwald wrote: Composition (and encapsulation) is way better than inheritance.
Not in all cases, but it should be considered before inheritance.
Daniel Grunwald wrote: without thinking
Doing anything (even sealing) without thinking will cause trouble in the long run.
|
|
|
|
|
Can you directly store the CheckState.Checked / Unchecked value in a class property?
If so how would you store it, or do I have to examine it and store a bool?
Thanks.
|
|
|
|
|
I don't think so, but you can attach a handler for the ItemCheck event.
|
|
|
|
|
If you need to track the checked items in the control, you can make use of CheckedIndices property.
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
So you cannot store the e.CheckState value in the ItemCheck event?
I have many collections to display/redisplay in the same checkedlistbox. I would rather push a value to the object in the list when it is checked then cycle through all of them before changing the collection being displayed. I have
if (e.NewValue == CheckState.Checked)
dv.checkedInLB = true;
else
dv.checkedInLB = false;
which works fine, but adds a step.
|
|
|
|
|
I haven't tried it, but I would expect something like:
((SomeType)checkedListBox1.SelectedItem).checkedInLB = e.NewValue == CheckState.Checked ;
|
|
|
|
|
If you keep the checked state in some other property, you will be checking that then. So any ways you will have to check by some mean or the another that check box is checked or not.
Am I understanding your problem correct or not? I assume you want to store checkedstate in a boolean property. Like:
if (checkedListBox.Items[index].checked){
}
else{
}
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://www.codeproject.com/script/Forums/Images/badger.gif)
