Archive for April, 2010

C# – goto, the spawn of satan

Oops, it’s been a week since I last posted but I guess I earned a break from working hard and I was struggling for an issue I came across recently. Then a quick google and I noticed some code that used something I haven’t seen since I was a teenager programming in locomotive basic on my Amstrad CPC 6128… a goto statement. I knew that C# does have this command and there are people out there who argue that it is useful. It probably is, but for the sake of your (and anyone who would be maintaining your code in future) sanity, DON’T do it!

I had another skim through the internet and found the following source code that uses goto:


for(int i = 0; i < size.Width; i++) { for(int j = 0; j < size.Height; j++) { Color c = Color.FromArgb((int)pixels[i,j]); if(c.A < 255) { hasAlpha = true; goto breakSpot; } } } breakSpot:

as you can see, the user is trying to iterate through a 2D array looking for a pixel with a value larger than 255 (meaning it has an alpha value) and is then exiting the loop. Despite this being a (relatively) safe usage of the goto statement, it makes for lazy coding.

How would I do it? well, here is what I'd do...


for(int i = 0; (i < size.Width && !hasAlpha); i++) { for(int j = 0; (j < size.Height && !hasAlpha); j++) { Color c = Color.FromArgb((int)pixels[i,j]); if(c.A < 255) { hasAlpha = true; } } }

Oooh, you didn't know you could do that did you? It's a for loop! You have a start value, an adjuster and a condition. The condition doesn't even have to have anything to do with the value used to count the loop. It generally does but it isn't required.

Anyway, I hope someone found that useful and that I've advanced the cause of the 'anti goto' movement. Enjoy!

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

C# – Interfaces… why?

Yep, you read right. Why on earth do we use interfaces? I’ve seen a plethora of crappy examples involving shapes, fruits, vegetables, etc. attempting to explain why we use inheritance and interfaces. Bloody useless! Why? They have no proper real-world application that we can associate with. Unless you’re a mathematician or a greengrocer, why on earth would you care about fruit or shapes?

Ok, lets start with a definition of an interface.

An interface is a contract of service within a programming language.

Ok, what on earth does THAT mean? It means when you implement an interface, you are agreeing to provide functionality that satisfies the interface contract.

So… what use is that exactly?

An interface would be a structure with no implemented methods. A (terrible) example from MSDN is:


interface IMyInterface: IBase1, IBase2
{
void MethodA();
void MethodB();
}

This defines an interface with two methods. MethodA and MethodB. It has no implementation code. It also can inherit other interfaces (IBase1, IBase2) so you can structure them. That’s more a FYI than anything because that complicates things far too much for the simple explanation I want to give out.

Interfaces can be very useful. Let’s use a real-world example that we should all be fairly familiar with. Let’s pick an ATM at a bank. (I pinched this example for a C# design book I picked up about 7 years ago. I don’t have the book to hand or recall the exact name. I may add it here at a later date)

A bank ATM has the following basic functionality:

– Enter Pin Number
– Check balance
– Pay in Money
– Withdraw Money
– Print Mini-Statement
– Sign out

If I pop over to my bank branch, I get a few more functions but that’s nice and simple for now. In the UK, we have a system called ‘LINK’. Basically, this allows account holders of a LINK member bank to use basic functionality at another LINK member bank’s ATM for free. Naturally, this would have limited functionality since it can get quite busy on banking networks and you really want minimal traffic so the banks will want to provide basic functionality on their ATMs for LINK member account holders. So, how do we guarantee the same functionality on all ATMs? Every bank functions slightly differently to the other so what are we going to do? Yep, that’s right, we use an interface!

The interface could be structured as follows:


interface ILinkFunctions:
{
double balance;

void CheckPin();
void ShowBalance();
void WithdrawCash();
void PayInMoney();
}

If every bank implemented this interface for their ATM software when dealing with LINK customers, they all get the same functionality!!

This now means that when you use a LINK machine, you will have the same basic functions wherever you go. Not only can you use this to guarantee that certain functionality exists, you can also use the interface as a type when making use of the functionality in other parts of your code. Here’s a simple example of that in use:


public void SpecificLinkFunction(ILinkFunctions source)
{
--Implementation here--
}

The above code allows you to make use of the knowledge that ILinkFunctions has certain guarantees. Think of how you could be writing a game in XNA and you want to process ALL sprites rather than have to process individual categories of sprite (baddies, hero, bosses, bullets, etc.). If all these sprite classes implemented an interface, you could process all sprites of that type in one simple function that made use of the interface they all share! Doesn’t that make life so much easier?

I’ve barely touched the surface here and I’m waffling on but a nice little example involving pencils is online here

Good luck!

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)