locked
Need a syntax for object inheritance RRS feed

  • Question

  • User1182587605 posted

    I am looking for an object inheritance example for the below scenario:

    Teacher object to inherit from the Person object.

    How can I do this?

    1. class teacher inherits a person
    2. class <g class="gr_ gr_146 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" id="146" data-gr-id="146">Teacher :</g> Person
    3. class Teacher -> Person
    4. class Person -> Teacher

    I somehow know that option 2 is not correct. Please explain me in detail what is the actual syntax for object inheritance.

    Friday, January 12, 2018 10:04 AM

All replies

  • User-284744251 posted

    If your question is related to C#, then Option 2 is correct

    http://csharp.net-tutorials.com/classes/inheritance/

    Friday, January 12, 2018 10:58 AM
  • User1182587605 posted

    Thanks, Gaurav,

    Unfortunately, that is wrong and I am still looking for a correct answer. The question is related to object inheritance, not a class or interfaces inheritance. Please check once again and help me find the right one.

    Saturday, January 13, 2018 1:33 PM
  • User753101303 posted

    Unclear, 1,3,4 won't compile and 2 is indeed correct.

    Try perhaps https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/inheritance

    Seems it might  be a wording issue. Stricly speaking object inheritance applies to ALL objects of this class because it has been defined at the class level.

    Saturday, January 13, 2018 3:31 PM
  • User-832373396 posted

    <g class="gr_ gr_21 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="21" data-gr-id="21">Hi</g> <g class="gr_ gr_5 gr-alert gr_spell gr_inline_cards gr_disable_anim_appear ContextualSpelling" id="5" data-gr-id="5">acmedeepak</g>,

    Teacher object to inherit from the Person object.

    As far as I know, based on your requirement, it could look like:

      public class Person
       {
                string _name;
                public string Name
                {
                    get { return _name; }
                    set { _name = value; }
                }
                public Person(string name)
                {
                    this.Name = name;
                }
       }
      public class Teacher:Person  
       {  
           public Teacher(string name)   
                 :base(name )  
         {
               this.Name = Name;
         }
       }

    So I think it is option 2;

    and you could show us the distinguishing feature of object inheritance maybe we could know what's that.

    With regards, Angelina Jolie

    Tuesday, January 16, 2018 7:17 AM
  • User303363814 posted

    If the domain that you are modelling has the concept of a Person then it is normal to have a Person class.  Each instance of that class represents a single human and every human of interest in the domain is represented by an instance of Person.

    After that basic start things can move in a couple of directions.  Object modellers tend to love inheritance and languages support it well but it is not always the best fit for a particular part of a domain.  Sometimes the concept comes to light that a particular human is not only a Person but that they perform a specialised role - that of a Teacher.  The first approach to modelling this is often to make Teacher a sub-class of Person but this is, reasonably often, not the best way.

    Consider a human joining the organisation as an administration officer.  An instance of a Person would be used to model that human.  Over time that Person instance will build up salary information, taxation information, job performance information, etc.  Now that human applies for and becomes a Teacher.  We need a new instance of type Teacher for this human who is no longer just  a Person.  It is very difficult to create the new Teacher instance and 'reconnect' all the 'Person' information to it before deleting the original Person instance (particularly if there is a database behind the object model)..

    More common in these situations where the 'type' of a particular 'thing' can change in some ways is to model the human as a Person but that the Person type understands the concept of job mobility - promotions.

    In practical terms ... you might want to consider having a Person class which each human in the domain is an instance of.  The Person class has an attribute of type Job.  The Job type can handle all the different roles that people play in the organisation, Admin Officer, Teacher's aid, Teacher, Head Teacher, Form Master, etc.  Now when a Person is promoted or changes their role in the organisation the basic Person instance remains the same but their Job changes.  The Job class can answer the question IsTeacher if you need it by its knowledge of the different roles.

    In more complex domains you may want to model a person job history.  Now a Person will maintain a list of Jobs each with the date of promotion.  The concept of IsTeacher would now have a time component, that is, "was the human fulfilling the role of a Teacher on a particular date?"

    Tuesday, January 16, 2018 10:15 PM