3. Repeating drawingContext.DrawEllipse is not as redutant as it looks like. Different methods might be used in future, e.g. DrawEllipse in the first method and DrawGeometry in the second one.
4. It's WPF, Pen doesn't have to be explicitely disposed.
1) the first method requires you to do a switch / if-then EVERYWHERE you call the functions so you can decide which one to call... the second method doesn't and its more self standing
2) you don't have any more HeadTypes NOW... and yes, I agree, music is probably not going to add another head type anytime soon, but the first method would require you to write a 3rd function and update every piece of calling code that decided whether to call the first two functions while the second method would only require you to update the single function and none of the calling code.
Both points aren't suitable to my specific scenario.
No, because this is from a NoteVisual class, which is base for e.g. QuarterNoteVisual. Every child class (quarter, half, full etc) use just one of these methods and does not do any switch.
It is possible to design a deeper inheritance
In that case, I'd *still* say the 2nd method is preferable
1) you have one base function to maintain vs two (or more)
2) base.Func(HeadTypes.Filled) and base.Func(HeadTypes.Unfilled) looks and feels cleaner to me
On the other hand, if you are drawing a *lot* (like 10's of thousands) of these notes and need to squeeze out every single iota of performance then the first method would probably be better since you can get rid of the switch and its associated jumps. From the code you posted, you have a *bit* of room for other improvements too, but getting rid of the switch for performance reasons will only come into play if you are calling these functions a *lot* (like 10's of thousands of times).
I agree with you in general, I wanted to make some adnotations to your post. BTW, I think that it would have to be *much more* than 10's of thousands to observe a differnce between switch vs override. My post was about coding style, not performance. BTW max number of calls will be ~50.
// Result should look something like this
string ... myArray = new ...
foreach (string in order myArray)
foreach (string address in myArray...)
Unfortunately I do not know how to declare a field and set
Be careful when using BitConverter. It uses the endianness of your CPU, so if you're byte array is coming from a hardware device with a different endianness, your BitConverter results will be messed up.
I store two kinds of data types (Bar1 and Bar2) in the same dictionary. Both data types dervies from Foo class. I would like to extract only the Bar2 elements from the dictionary.
Here is what I got:
class Bar1 : Foo
class Bar2 : Foo
staticvoid Main(string args)
Dictionary<string, Foo> foos = new Dictionary<string, Foo>();
for(int i = 0; i < 5; i++)
foos.Add("Bar1." + i, new Bar1());
for (int i = 0; i < 10; i++)
foos.Add("Bar2." + i, new Bar2());
List<Bar2> bar2List = new List<Bar2>();
foreach (Foo foo in foos.Values)
if(foo is Bar2)
Are there any other method to extract the Bar2 elements from the dictionary into the Bar2 array (bar2List) instead of using foreach-loop and if-statment?
List<Bar2> bar2List = foos.Values.Where(f => f is Bar2).ToList<Bar2>();
... should do it.
Linq-to-objects like this is essentially doing the same thing as the foreach loop in your original suggestion, so performance wise you will gain nothing, but some people will say that the Linqed code is more readable (and in this case I think I'd agree with that).
(Ed: putting the type parameter on Where doesn't work, it tries to cast items before checking them.)