Why there is a concept called shadowing/waht probleam it solves

Quote:

In shadowing, we provide a new implementation to the base class member
without overriding it. We may shadow a base class member in a derived class, by
using the keyword shadows. The access level, return type, and the signature (means
the datatypes of the arguments passed & the order of the types) of the
derived class members which are shadowed, may differ from the base
class.

In C#, we may
achieve shadowing using the keyword new. However, when Hiding in C#, the access
level, the signature, return type of the derived class must be same as the base
class.

First, let's define 'shadowing/hiding as the functionality in a programming language that allows names/identifiers to have a different meaning/function/value in different places in your program.

Without this functionality, a computer language, like BASIC, or JavaScript/EcmaScript, defines all variables (names) as global. Such languages, experience has shown, are more prone to bugs and creating code that is difficult to maintain.

'Shadowing/hiding is one aspect of a computer language's facilities for structuring "scope," the control of semantic space. Another way to say that is that shadowing/hiding is part of the general strategy of encapsulation and modularity common to modern programming languages.

In modern OOP languages, shadowing/hiding is used in inheritance: a derived class can define a method with the same name as a method in the base class it inherits from, but that method can extend or replace the behavior of the base class method.

Suggested reading:

ex-Microsoft C# guru Eric Lippert: [^].

Good discussion here, many points of view: [^].

Please see my comment to the question. Asking "why" makes little to no sense.

I think by "shading" you mean something more correctly called "hiding". "Shading" is just a pretty misleading word some use. See by yourself.

First of all, you should understand that hiding is not any useful OOP concept. It does not even related to the essence of OOP. Rather, it is a by-product of the syntax related to what I call one of the prerequisites to "real" OOP, inheritance. Let's see. All members of a base class are inherited by a derived class. What happens if someone, by one or another reason, creates some member in the derived class, with the same name, type/signature as some existed, inherited member?

There can be different approaches to this situation. The simplest solution would be prohibiting this. But, traditionally, it is allowed. In C#, just the warning is issued; and it can be suppressed. For example:

class Base {
    internal void SomeMethod(); // important: not virtual, cannot be overridden
}

class Derived : Base {
    // compiler will issue the warning:
    internal void SomeMethod(); // in fact, a different method, unrelated to Base.SomeMethod
    // it hides Base.SomeMethod
}

In what sense does it hide the method? Let's see the usage:

Derived derived = new Derived();
derived.SomeMethod(); // which one is called? Derived.SomeMethod
// and Base.SomeMethod is hidden. So, how to call it:

// here is how:
Base base = derived; // it is assignment compatible, because Derived is Base
// (but Base is not always Derived
base.SomeMethod(); // now Base.SomeMethod is called on the instance derived

Note that runtime type of derived is Derived, and its compile-time type used to call the hidden method in the last line is Base.

The hiding can be considered as the result of someone's mistake. There is nothing useful in it, but the way it works allows for the work-around I just demonstrated.

And this is how the warning is suppressed:

class Derived : Base {
    internal new void SomeMethod(); // no warning
    // it just tell the compiler:
    // "Yes, hiding; I know. Just relax.
    // My name is Sledge Hummer; I know what I'm doing." :-) 
}

Good luck.

—SA