C# protected property, setter and getter

Question

This code is copied from the first page of lesson in Inheritance & Polymorphism > Protected Members in C# Intermediate.

I admit I haven't finished module Inheritance & Polymorphism yet, but I'm curious how to change the property of a protected member.
First thing comes to my mind is a setter and getter. However, the Name property is declared inside the parent class, it seems it is not logical to override the Name in Student child class.
Then I added two functions to simulate the setter and getter behavior, which are the ChangeName and GetName method.
Is it the correct way to update a protected property? By "correct" I mean is it the preferred way?

As a side question, why "this" is not present in line 17?
I found this work the same with or without it.
However, without "this", how come the program able to distinguish object between s and s2?
https://sololearn.com/compiler-playground/c01iiDl1XACR/?ref=app

Answer 1

Another approach would be to create an abstract superclass with an abstract property.
Or in the superclass you can mark the property with the virtual keyword.
In both of these cases you can override it in the subclass (and define a different getter or setter).
But in neither case would it make sense to me, to make the property 'private'. At least if you want to make it accessible from outside (the Main method).

Regarding your side question, "this"is not needed because the property name is clearly different from the method argument name, and the Name is not static, therefore each instance has its own dedicated property.

Example of virtual and override, with a protected backing field and public property.

https://sololearn.com/compiler-playground/ckxm86xbKdvJ/?ref=app

Answer 2

In my opinion, inheritance is the worst feature of OOP. I try to avoid when possible. (Interfaces are cool though.)

https://softwareengineering.stackexchange.com/questions/360708/are-protected-properties-evil

It is really difficult to come up with a meaningful use case for a protected property, that is simple enough for a beginner to understand. We can use it if we want to implement some functionality in the superclass, and only want to allow the subclasses to use it.

Often the property is also implemented with a backing field whose name starts with underscore.

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-properties

The approach you took to enable the subclass to change the property, seems reasonable if you are not allowed to change the superclass. But having to come up with these weird names for the same functionality of a getter and setter, indicate a design problem to me.

Answer 3

When I posted this question, I haven't learned about virtual, abstract and interface yet. After finishing that module, it seems using them actually make more sense and allow more flexibility.

Interestingly, SL doesn't teach us to use underscore for fields, instead they use lowercase for fields and capitalize case for properties during the course. And I thought that is the convention much like starts with capitalize I for interface they teach us.

And looking at the syllabus, I don't see they mentioned lambda declaration operator "=>". By looking the code I just assume it means "which is" in layman terms.

Maybe I will restart Intermediate of Java and JS since they share much common in syntax and structure, or better yet start MS Learn at the same time for cross reference.

Answer 4

Expanding on Tibor Santa's excellent answers, you can use the 'new' keyword if you want to reuse the parent class method name but want to change the security level. override cannot do this.

https://sololearn.com/compiler-playground/ceq32Fq2sMMD/?ref=app

Answer 5

SL can only teach basic concepts, and it is always a few years behind the new language version updates. Coupled with the crippled input system, it is not ideal for advanced exploration and learning.
But it is good for new learners who would be overloaded with too much information if they try to learn coding without bite-sized lessons.
I found that if you want a deeper understanding, the best thing to do is to go down the rabbit hole of api documentation, SO discussions, blogposts and lots of experimentation.
Then you would probably forget it all in a few weeks or so. But hopefully a vague memory of the process and concept remains so you can search for it the next time you get stuck.