Blogs Home

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...