How abstraction is achieved through abstract methodsa and abstract classes?

"Abstract," can be both noun, adjective, and verb, in English; in general OOP context we can say that 'Abstract Classes or Methods express virtual (or meta-) information, information which may be used (is required to be used) by other Classes, or Methods that inherit from them.

"Abstraction" can mean both a principle of OOP design (noun), and refer to the process (verb) of creating abstract entities in design, and code.

To bring this "down to earth:" in C# .NET, the 'Abstract keyword signifies that a Class is an entity which:

0. is intended to be used as a "provider" of both/either template definitions (abstract members) and implementations of "real" Methods (non-abstract) to Classes that inherit from it.

if everything in an Abstract class is declared 'abstract: then you can say that that Class is equivalent to a Virtual Class. "Real" methods that the Abstract Class implements can be considered as providing "default" behaviors to inheritors.

And that other Class Members declared 'abstract have no "implementation."

1. it can not be instantiated with 'new. so, don't define a public constructor.

2. it cannot be sealed.

3. it cannot have any members (Properties, Fields, Methods) declared 'private

4. it doesn't support multiple inheritance (cannot inherit from Class or Interface)

5. 'abstract Methods cannot declare bodies

So, what does using an 'Abstract Class do for you ?

1. let's you combine some features of

a. Interface ... inheritors from non-abstract Classes must implement each Class member declared as 'abstract

... and ...

b. a "regular" Class that provide build in implementations that the inheriting Class can use, or over-ride.

2. extendable in a way that does not "break" Classes that inherit it.

While this is a short (and dense, and advanced) small article, I think reading this may give you an idea of the power (extendability) possible using the 'abstract/'override synergy to regulate the behavior of Classes: [^].

Here's a somewhat fanciful example of usage of an Abstract Class:

using System;

namespace AbstractClassNameSpace
{
    // show that an abstract class can inherit from an Interface
    interface someInterface
    {
        int someInt { set; get; }
        string someString { set; get; }
    }

    // demonstrate how an abstract class can allow poor design choices !
    // that don't cause compile-time errors: i.e., fields with duplicate names
    interface someOtherInterface
    {
        int someInt { set; get; }
        string someString { set; get; }

        double someBigNumber { set; get; }
    }

    public abstract class AbstractSandBox : someInterface, someOtherInterface
    {
        // required "implementation" of Interface properties can be 'abstract
        public abstract int someInt { get; set; }
        public abstract string someString { get; set; }

        // required "implementation" of Interface property can be an implementation
        public double someBigNumber { get; set; }

        // an implementation not required by inherited Interfaces
        public double hypotenuse(double sidea, double sideb )
        {
            return Math.Sqrt((sidea*sidea) + (sideb*sideb));
        }

        // an abstract Method not required by inherited Interfaces
        public abstract string someWeirdStringStuff(string a, string b);
    }

    public abstract class SomeInheritingClass: AbstractSandBox
    {
        // required by inheritance from Abstract Class
        public override int someInt { get; set; }
        public override string someString { get; set; }

        // not required, and we can't override it
        // but we can hide it, by declaring it with 'new
        // and access the Abstract Class implementation
        // using the keyword .base
        public new double hypotenuse(double sidea, double sideb)
        {
            // call the base method in the Abstract Class
            double hyp = base.hypotenuse(sidea, sideb);

            // we're in a different galaxy now with different geometry
            // where we have to translate :)
            return hyp / Math.E * Math.PI / Math.Log10(hyp);
        }

        // required implementation of Abstract Method defined in from Abstract Class
        // but, by declaring it abstract override we express our intent
        // not to "use it" in this class, but to only use it from inheriting classes
        public abstract override string someWeirdStringStuff(string a, string b);
    }

    // non-abstract Class
    public class GrandchildofAbstractClass : SomeInheritingClass
    {
        public void AccessParentClass()
        {
// set break-point here
            Console.WriteLine(this.hypotenuse(3.0, 4.0));
            Console.WriteLine(this.someWeirdStringStuff("whoops", "adaisy"));
        }

        // accessing the implementation in the Abstract Class 'AbstractSandBox
        public void UseAbstractClassSandBox(string a, string b)
        {
// set break-point here
            Console.WriteLine(this.someWeirdStringStuff(a, b));
        }
    }
}

If you are "up for it," I suggest you paste this code into a Project in Visual Studio, then add break-points in the code for the GrandchildofAbstractClass in both the
AccessParentClass and UseAbstractClassSandBox Methods.

Then, add your own code to create an instance of the 'GrandchildofAbstractClass, and try calling those methods, passing values as required.

Single-step through the code with F11 and watch the flow-of-control.