|
BobJanova wrote: also smells
Agreed, but where I'd disagree is here:
BobJanova wrote: because it's harder to see that that's what you're doing.
I'd say having the condition visible at each branch is more clear, but that is a matter of opinion.
BobJanova wrote: If he's switching on this enum in several places, perhaps the class hierarchy should be adjusted so that it is not an enum
Yes, and the article I pointed him to makes this very point. As I said, he might not have the luxury of altering that much (the graphics classes are riddled with enums, forcing attendant switches), so I gave him another option.
|
|
|
|
|
About the second point: the reason the switch is clearer is because you can see immediately when you see the word 'switch' that it is going to be a selection based on a single value. With the if/else there's nothing to stop you doing
if(c == ' ') ...
else if(c == '/') ...
else if(c == '^' && accountBalance > 50) ...
else if(c == '&') ...
... so you have to read each line carefully to know what the logic is actually doing.
|
|
|
|
|
I demonstrate using Action to perform functionality instead of using a switch (or an if/else condition) in this[^] blog post.
|
|
|
|
|
BobJanova wrote: class tree with a Render method
I have considered it but it has prons and cons too -- see my answer to "SledgeHammer01"[^].
Greetings - Jacek
|
|
|
|
|
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.
Greetings - Jacek
modified on Tuesday, June 28, 2011 6:59 AM
|
|
|
|
|
Second, kinda. Edit: The second is the better of those two.
3) Have a NoteHeadInfo class (or structure) that contains the sizing factor and a reference to the pen and pass one in.
3.a) Have a Dictionary<NoteHeadTypes,NoteHeadInfo> and use it in your second example.
modified on Tuesday, June 28, 2011 9:46 PM
|
|
|
|
|
The second for a trillion reasons:
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
Note
abstract ~RenderHead
FilledNote
+RenderHead
QuarterNote
and
Note
abstract ~RenderHead
EmptyNote
+RenderHead
HalfNote, FullNote
But this would make the code too javaish -- superdeep inheritance which quickly become hard to maintain.
Greetings - Jacek
|
|
|
|
|
Ah, ok, so if I'm to understand, its more like:
HalfNote.Render -> call base.Func1()
QuaterNote.Render -> call base.Func2()
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.
Greetings - Jacek
|
|
|
|
|
Hello,
There Service07.Eso9PortClient class that contains method getOrders () which returns an array of orders.
Each order contains information (address, folders, etc.).
I need to convert these orders into an array or collection so that I could browse and handle these orders.
Could someone advise me how to do it?
/ / Order to convert the array or collection / /
/ / Orders
Service07.Eso9PortClient orderClient07 Service07.Eso9PortClient = new ();
Service07.Order [] orders = orderClient07.getOrders ();
foreach (Service07.Order order in orders)
{
/ / Order addresses
Service07.Address [] addresses = order.Addresses;
foreach (Service07.Address address in addresses)
{
/ / Addresses attributes
Service07.Attribute [] = addressAttributes address.Attributes;
foreach (Service07.Attribute addressAttribute in addressAttributes)
{
string = addressAttributeName addressAttribute.Name;
string = addressAttributeValue addressAttribute.Value;
}
string = addressCity address.City;
string = addressCompany address.Company;
string = addressCountry address.Country;
}
/ / Order attributes
Service07.Attribute [] = orderAttributes order.Attributes;
foreach (Service07.Attribute orderAttribute in orderAttributes)
{
string = orderAttributeName orderAttribute.Name;
string = orderAttributeValue orderAttribute.Value;
}
/ / Order Coupon
string = orderCouponCode order.Coupon! = null? order.Coupon.Code: null;
string = orderCuponValue order.Coupon! = null? order.Coupon.Value: null;
/ / Order Created
string = orderCreated order.Created;
/ / Order items
Service07.OrderItem [] items = order.Items;
foreach (Service07.OrderItem item in items)
{
string itemName = item.Name;
string = itemNote item.Note;
}
}
// 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 
Thank you for your answer
|
|
|
|
|
Please format the code properly; it is unreadable in this way and try to provide the code examples that will actually compile (and not as this string = addressAttributeName addressAttribute.Name;)!
|
|
|
|
|
Dear All,
How can i read values from Byte Array?
Regards,
DJ.
|
|
|
|
|
The easiest way to read the data is to loop over the array. Here's a typical method for doing this:
for (int i = 0; i < myArray.Count; i++)
{
byte value = myArray[i];
}
|
|
|
|
|
|
You can read larger base types from a byte array with BitConverter[^].
|
|
|
|
|
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.
See BitConverter.IsLittleEndian[^]
Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
|
|
|
|
|
Indeed. Most platforms agree on endianness but particularly if you deal with embedded systems this can be a concern.
|
|
|
|
|
Actually i don't want its size. I need to get the value.
When i iterating it displays the size.
How can i get the value behind each array item?
|
|
|
|
|
Since your question mentioned a byte array, the size of each item is 1 byte.
Pete O'Hanlon mentioned the item count within the array. One could call that a size, too.
DJ245 wrote: When i iterating it displays the size.
What size exactly do you mean by this?
DJ245 wrote: How can i get the value behind each array item?
Each item's value is exactly what Pete O'Hanlon's answer is concerning with.
Ciao,
luker
|
|
|
|
|
Please check the screenshot
http://doubts.posterous.com/bytearray-doubt[^]
Actual value in the byteArray[0] is Name of an employee, [1] is code and son on...
When iterating it returns only its size.. How can i get the Name of Employee from byteArray[0]?
|
|
|
|
|
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:
abstract class Foo
{
}
class Bar1 : Foo
{
}
class Bar2 : Foo
{
}
class Program
{
static void 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)
{
bar2List.Add((Bar2)foo);
}
}
}
}
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?
|
|
|
|
|
could give LINQ a whirl...
using System.Linq;
List<Bar2> bar2List = (List<Bar2>)foos.Values.Where(f => f is Bar2).ToList();
...it compiles but I didn't run it
If my jokes make me laugh, then I have already succeeded with 100% of my target audience
|
|
|
|
|
Didn't work: InvalidCastException...
Unable to cast object of type 'WhereEnumerableIterator`1[ConsoleApplication1.Foo]' to type 'System.Collections.Generic.List`1[ConsoleApplication1.Bar2]'.
Some other solution?
|
|
|
|
|
I think
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.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
