(Basic) The first "thing". A class, or an interface?

Background

I'm trying to share what hopefully would be a usefull tutorial for anybody who wants to understand design patterns. I will make it so simple any first grader computer student would understand. I won't tell you where this tutorial will end up, on purpose, so we can focus on one material at a time. Oh yes, and actually, you could correct my grammar at anytime because English is not my native language, and I will thank you for that. How wonderful life is when we could teach each other, isn't it?

Before we begin

• This is not a Visual Studio (VS) tutorial, so you need to be familiar with VS first.
• This material is very basic, and it's not intended for any IT professionals by any means.

So, let's start, shall we?

Once, in this universe, I believe there was only one "thing". In programming world there won't be any difference. When we start from the beginning, we start with "nothing", and then we will come up with one "thing".

Many times, we never really know what this "thing" would become. It's so abstract, that all we can say right now is "it must have a name (for us) and an ID (for you, processor)" to differentiate between "things" in the future. That when the term "Interface" comes into play.

Interface is only a contract, about how the implementation will be constructed in the future. It's not about how the implementation will actually work.

So, let's start with this (divine) pattern first, A.K.A "the first interface we can define at the first place" :

Interface

public interface IThing
{
    string Name { get; }
    int Id { get; }
}

"Oh come on, it doesnt mean a thing, yet". Yeah, sure. At least we got something to start working on, ok?

Why an interface? How about using a class, instead?

By the time you read this, I guess you already know about the other term "Class". In this case, I could say, you won't find any particular reason why you can't use a class, instead.

Mostly, when we're talking about class, we're talking about implementation. But there is a type of class that is not intended to use for implementation. We call this class an "Abstract Class".

Abstract class is originally intended for an abstraction only. It cannot be instantiated, thus you need to inherit it first to do so. In this case, it's similar with the interface. So let's just create the other "first thing" using an abstract class then.

Class

public abstract class CThing
{
    public abstract string Name { get; }
    public abstract int Id { get; }
}

There you are. See, I'm an open minded guy, you know.

What we have learned so far?

###Interface is only a contract, about how the implementation will be constructed in the future. It's not about how the implementation will actually work.

###Abstract class is originally intended for an abstraction only. It cannot be instantiated, thus you need to inherit it first to do so.

We won't discuss the differences between these two any futher yet. So, from now on, just let them lead us to meet their destiny, ok?

What's next?

We will meet the first generation of these "first things" in my next article, when we talk about the concept of "inheritance".