Learn C#: Method Hiding (and Why You Will Want To Avoid It) 

I've only ever used "property hiding" in a derived generic class. Where the base object has a property of type "object" or "SomeOtherBaseClass" but the derived generic version "Derived" would represent that same property as T. It doesn't change how the property works it only casts it to a more specific type.

"new void" seems like a new way to give programmers a PTSD LOL Great video, man

DONT DO IT, YOU WILL REGRET IT.

I feel like you should have mentioned explicit interface implementation. 1. You can implement a method explicitly only in the interface without resorting to method hiding (because of name clashes). 2. You cannot access this method which would otherwise be hiding a base method through any other means than via the interface. 3. Polymorphism is observed when using the objects via the interface contracts.

I hit the opposite problem recently with the base and derived classes both implementing INotifyPropertyChanged, used to trigger update events in bound WPF user interfaces. We had to refactor away the derived class implementing INotifyPropertyChanged to fix the binding again. Quite subtle.

Thank you so much for this explanation. I come from Java world and I have been racking my brain for days trying to figure out why on earth is this even required. It's completely counterintuitive. And as you mentioned, it is a bad idea overall.

Heres the pattern that revolves around my only use case: public class MyClass(object value) { public object Value { get; } = value; } public class Derived(string value) : MyClass(value) { new public string Value => (string)base.Value; } However I'd rarely write code like this, as I would put MyClass into an interface unless its unfeasible. For example: public interface IConfigurationBinding { object Value { get; } void Serialize(BinaryWriter writer) void Deserialize(BinaryReader reader); } public interface IConfigurationBinding : IConfigurationBinding { new T Value { get; } } public class Int32ConfigurationBinding : IConfigurationBinding { public int Value { get; private set; } object IConfigurationBinding.Value => Value; public void Serialize(BinaryWriter writer) => writer.Write(Value); public void Deserialize(BinaryReader reader) => Value = reader.ReadInt32(); } This way, I can have a list of IConfigurationBindings without knowing their type and I can serialize and deserialize them. I can also check if its a specific type using the type interface. This may be useful in situations where you might read/write the representations of the value differently, or it even can store multiple values. A great example is an implementation using Ticks of DateTime and DateTimeOffset. A class wouldnt work as I could only have one concrete inplementation. The implementing class would implement both IConfigurationBinding, IConfigurationBinding, and IConfigurationBinding. Wish there was a way to change a property nullability without hiding the property as that has come up on occassion.

Very nice explanation. Thanks

I did it once, and the manager change the base method to abstract and then used 'override' keyword in the child class. So I learnt my lesson in the hard way

So this begs the questions as to why was this feature included in the first place? Is there a valid use case?

you sounds mysterious!!!

I didn't know the subtly with the Interface, but we don't allow method hiding, just hideous. Doesn't it break LSP?

Thanks, I really hate it. But at least you can't attach properties to functions like you can in JavaScript. Yes, JS is that cursed!

var thing = new void();

Its really head acke

Use AI voice in these videos, your channel will explode. Your content is great, Your voice...not so much, i hate to write it and i feel uncomfortable with what i wrote, but its true and stops from this channel to become what it should become.