Need help on understanding few OOP & programming related concepts

Question

I been struggling to understand few concepts but no success yet. Can someone help me to understand that with simple example and definition please.

1 - Delegates in .NET

2 - Abstraction

3 - Three tier architecture

Thanks

Answer 1

Delegates in C#: Think of a delegate as a class, but an instance of that class would be a method rather than an object. The delegate is defined by the signature of the method which will be assigned to it. The instance variable may be called as if it were the method itself.

Given this example:

public delegate string StringWrapperDelegate(string input);

public string WrapInSquareBrackets(string input)
{
    return string.Format("[{0}]", input);
}

public string WrapInChevrons(string input)
{
    return string.Format("<{0}>", input);
}

public void DisplayWrappedString(StringWrapperDelegate wrapper, string input)
{
    Console.WriteLine(wrapper(input));
}

You can now call DisplayWrappedString, passing either of the WrapInXxx methods as an argument, for example:

DisplayWrappedString(WrapInChevrons, "test");

Abstraction: This is very much a conceptual thing meaning "anything which hides implementation details from the calling code." A delegate is a good example of this, as seen above. DisplayWrappedString knows nothing of the implementation of the wrapper method it is calling.

Three-tier architecture: This is where there is a physical or notional boundary between the presentation layer (strictly UI logic, which should be minimal), the business layer (all business rules and logic) and the data layer (data access code, also minimal).

The presentation layer generally communicates user requests to the business layer, which in turn accesses the data layer if it needs to. The important part of this, conceptually, is that the presentation layer should not talk directly to the data layer.

Answer 2

Delegates are quite simply functions as objects. You can create them, pass them around, and then call them when you like. You could trivially convert a delegate into a polymorphic class with a method, for example.

public delegate int SomeFunc(int);
public int Square(int i) {
    return i * i;
}
public int Double(int i) {
    return i * 2;
}
public int Func(int x) {
    SomeFunc f = null;
    if (someCondition) {
        f = Square;
    } else {
        f = Double;
    }
    return f(x);
}

This could be trivially converted to

public interface SomeFunc {
    int DoWork(int);
}
public int Square(int i) {
    return i * i;
}
public class SomeFuncSquare : SomeFunc {
    int DoWork(int) { return Square(int); }
}
public int Double(int i) {
    return i * 2;
}
public class SomeFuncDouble : SomeFunc {
    int DoWork(int) { return Double(int); }
}
public int Func(int x) {
    SomeFunc f = null;
    if (someCondition) {
        f = new SomeFuncSquare();
    } else {
        f = new SomeFuncDouble();
    }
    return f.DoWork(x);
}

Of course, at the machine level, they might look much different, depending on what you're doing. But they might not.

Abstraction is the principle of hiding. Basically, an abstraction hides everything except what you need. A simple real example is a wall socket. It takes any electrical device that fits in the hole. The key here is the "any" that allows you to make your own device and plug it in without having to build new sockets and such. The exact same principle applies in computer science- you want to make something that can do as much as possible with as little modification as possible, and the way that you do it is that you only define what you really need. Do you really need to take a List<T> when you only enumerate over it? No, IEnumerable<T> would be a better choice, because you only need to enumerate over it, and actually, you could take anything that can be enumerated. The important thing here is the "anything", meaning you can change it later if you want and not have to re-write. This will save you time when you come to pass in something else, like a LinkedList or a Queue or whatever.

Any generic function is an example, because they don't actually depend on the types they operate on. When you write a container, you typically don't need to know the contained type. So the one abstract container can contain anything.

Three-tier architecture? No idea.

Answer 3

For me I finally understood delegates when I thought of them as an Interface for a Function (Being as I am a VB person). Or, more generally, a Method Interface. Of course I first had to understand the significance of what an Interface is. And to understand the Interface concept I had to understand what a Class is.

So when all that knowledge was condensed into wisdom Delegates made a lot of sense and events became understandable in the big picture. When That happened I found out why abstraction made sense and then I realized why N-Tier (with 3 being one of the N's possible) architecture was so appealing on anything other than trivial applications.

It is questions like these which force me to appreciate not only how much I know but how much I don't know.

So.... Your question is, well, very broad and I don't know if anybody could really answer your question without knowing your actually level of knowledge and the wisdom you have obtained from that knowledge (ie how much experience you have with the knowledge).

BUT the simple fact you ask about abstraction leads me to believe, though I could be wrong, that you would not be able to truly understand any answer given because abstraction is the heart and soul of programming computers to do things humans appreciate.