Part Four: Interfaces

If you've read parts 1-3 of this blog you'll be aware that we've used the real world objects, cars, to draw a parallel with, and explain, classes, inheritance and abstraction. I hope that, by this stage, you are beginning to undertand and recognise the advantages that come from properly object orienting your code. Flexibility for future development is a key aspect of proper OO design. Although the code examples in this BLOG have been written in C#, one of the .NET languages, the principles apply to all Object Oriented languages.

So, we now come to Interfaces. What role do they have in object oriented programming?

Contracts...

Part Three: Abstraction

All of us are aware of abstract concepts, although perhaps we aren't aware that we're aware. To explain... all of us know that there are things we can touch, possess, and things that we can't. For example, we all eat food, but we never actually have a food. Food is an abstract concept and we actually eat instances of food - apples, hamburgers, pizzas, carrots, etc.

Abstraction is at the top level of most things we're familiar with on a day to day basis. In our Ford Focus illustration we were dealing with a concrete instance of an abstract concept - vehicle. Although a person may be said to own a vehicle, it's meaningless without specifying the type of vehicle he or she possesses. For most of us this is a car, but for some it might be a plane, a boat, a bike, a helicopter etc. We then further solidify things by becoming more and more specific about things - what make, model, variation of car we have, for example...

An Introduction to Interfaces, Abstract classes and Inheritance

Introduction

.NET Developers come in various shapes and sizes, not only physically, but also in terms of their expertise and experience. The polymorphic nature of the .NET Framework now allows their code to benefit from similar diversity. Sadly, though, it is entirely possible with .NET languages and tools, such as Visual Studio 2008, for developers to build programs and web sites without necessarily needing to know or understand the underlying complexity of what they are doing. I've come across so-called developers whose approach to solving problems has greatly improved their search engine skills as they scour the internet for code samples they can lift to fix the problem they're currently facing. Sadly, though, their attitude towards actually understanding and getting to grips with the problem domain is one of laziness...

Delegates are fundamental to the .NET Framework (events and callbacks wouldn't work without them) and can be extremely powerful to the .NET Developer once they come to grasps with exactly what they are and how to use them. In this blog I will consider aspects of a real world situation in which delagates are useful, after which I will explain, in illustrative terms exactly what delegates are all about. You will see how delegates are an intrinsic part of the events structure in the .NET framework, but also why they are useful in their own right. First, though, we need to understand a little about the origins of delgates in the .NET framework.

The origins of delegates

Delegates in .NET languages such as C# and VB.NET are akin to function pointers in C++. I have found that simply being aware of this pseudonym it extremely helpful in understanding delegates. The term helps us to understand that delegates allow a developer to provide a pointer to a method/function/sub etc. But when would a developer find this to be useful?...