Is this the only way to make inherited objects?












-1















public class Animal
{
public String name;
public boolean legs;
public boolean eyes;

public Animal(String name, boolean legs, boolean eyes)
{
this.name = name;
this.legs = legs;
this.eyes = eyes;
}
}




public class Dog extends Animal
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
{
super(name, legs, eyes);
this.vacinated = vacinated;
this.rabid = rabid;
}
}




public class Bulldog extends Dog
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public String breedtype;

public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
{
super(vacinated, rabid, name, legs, eyes);
this.breedtype = breedtype;
}
}


As you can see, if this keeps going on and on, in other words, if I have a really long inheritance line, would I seriously need to list out every single variable over and over again? I just feel like there is a a much more efficient way to do this.










share|improve this question























  • would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

    – BackSlash
    Nov 23 '18 at 8:08













  • So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

    – Andrew
    Nov 23 '18 at 8:11











  • No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

    – Andy Turner
    Nov 23 '18 at 8:12











  • @Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

    – BackSlash
    Nov 23 '18 at 8:12











  • You need a tutorial in objects and classes, not this site.

    – Raedwald
    Nov 23 '18 at 9:38
















-1















public class Animal
{
public String name;
public boolean legs;
public boolean eyes;

public Animal(String name, boolean legs, boolean eyes)
{
this.name = name;
this.legs = legs;
this.eyes = eyes;
}
}




public class Dog extends Animal
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
{
super(name, legs, eyes);
this.vacinated = vacinated;
this.rabid = rabid;
}
}




public class Bulldog extends Dog
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public String breedtype;

public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
{
super(vacinated, rabid, name, legs, eyes);
this.breedtype = breedtype;
}
}


As you can see, if this keeps going on and on, in other words, if I have a really long inheritance line, would I seriously need to list out every single variable over and over again? I just feel like there is a a much more efficient way to do this.










share|improve this question























  • would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

    – BackSlash
    Nov 23 '18 at 8:08













  • So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

    – Andrew
    Nov 23 '18 at 8:11











  • No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

    – Andy Turner
    Nov 23 '18 at 8:12











  • @Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

    – BackSlash
    Nov 23 '18 at 8:12











  • You need a tutorial in objects and classes, not this site.

    – Raedwald
    Nov 23 '18 at 9:38














-1












-1








-1








public class Animal
{
public String name;
public boolean legs;
public boolean eyes;

public Animal(String name, boolean legs, boolean eyes)
{
this.name = name;
this.legs = legs;
this.eyes = eyes;
}
}




public class Dog extends Animal
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
{
super(name, legs, eyes);
this.vacinated = vacinated;
this.rabid = rabid;
}
}




public class Bulldog extends Dog
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public String breedtype;

public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
{
super(vacinated, rabid, name, legs, eyes);
this.breedtype = breedtype;
}
}


As you can see, if this keeps going on and on, in other words, if I have a really long inheritance line, would I seriously need to list out every single variable over and over again? I just feel like there is a a much more efficient way to do this.










share|improve this question














public class Animal
{
public String name;
public boolean legs;
public boolean eyes;

public Animal(String name, boolean legs, boolean eyes)
{
this.name = name;
this.legs = legs;
this.eyes = eyes;
}
}




public class Dog extends Animal
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
{
super(name, legs, eyes);
this.vacinated = vacinated;
this.rabid = rabid;
}
}




public class Bulldog extends Dog
{
String name;
boolean legs;
boolean eyes;
public boolean vacinated;
public boolean rabid;
public String breedtype;

public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
{
super(vacinated, rabid, name, legs, eyes);
this.breedtype = breedtype;
}
}


As you can see, if this keeps going on and on, in other words, if I have a really long inheritance line, would I seriously need to list out every single variable over and over again? I just feel like there is a a much more efficient way to do this.







java inheritance this parent super






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 23 '18 at 8:05









AndrewAndrew

31




31













  • would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

    – BackSlash
    Nov 23 '18 at 8:08













  • So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

    – Andrew
    Nov 23 '18 at 8:11











  • No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

    – Andy Turner
    Nov 23 '18 at 8:12











  • @Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

    – BackSlash
    Nov 23 '18 at 8:12











  • You need a tutorial in objects and classes, not this site.

    – Raedwald
    Nov 23 '18 at 9:38



















  • would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

    – BackSlash
    Nov 23 '18 at 8:08













  • So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

    – Andrew
    Nov 23 '18 at 8:11











  • No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

    – Andy Turner
    Nov 23 '18 at 8:12











  • @Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

    – BackSlash
    Nov 23 '18 at 8:12











  • You need a tutorial in objects and classes, not this site.

    – Raedwald
    Nov 23 '18 at 9:38

















would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

– BackSlash
Nov 23 '18 at 8:08







would I seriously need to list out every single variable over and over again? - No. Your variables are public, you can access them from child classes. If you decide to follow the standard and make them private you will still be able to acces them via setters and getters. So, in both cases, no, you don't have to repeat them.

– BackSlash
Nov 23 '18 at 8:08















So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

– Andrew
Nov 23 '18 at 8:11





So i dont need to re-declare them, but i DO need to have them in my constructors as parameter variables?

– Andrew
Nov 23 '18 at 8:11













No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

– Andy Turner
Nov 23 '18 at 8:12





No. You currently have multiple name variables in the same class. Since member variables aren't polymorphic, this will near-certainly not do what you expect.

– Andy Turner
Nov 23 '18 at 8:12













@Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

– BackSlash
Nov 23 '18 at 8:12





@Andrew Yes, you still need them in constructor. But you can call super(...) as you are already doing to avoid re-assigning them.

– BackSlash
Nov 23 '18 at 8:12













You need a tutorial in objects and classes, not this site.

– Raedwald
Nov 23 '18 at 9:38





You need a tutorial in objects and classes, not this site.

– Raedwald
Nov 23 '18 at 9:38












3 Answers
3






active

oldest

votes


















0














Your classes are violated OOP. You should define common properties which could be inherited to child classes by protected. It means child classes can access those



Secondly, the common properties should be defined in parent class and dont need to be re-created in child ones.



P/S: updated by BlackFlash comment. I will use private modifier for such common properties. In the scope of this question, child classes don't need to access parent's properties.



Your classes should be changed as follows:



public class Animal
{
private String name;
private boolean legs;
private boolean eyes;

public Animal(String name, boolean legs, boolean eyes)
{
this.name = name;
this.legs = legs;
this.eyes = eyes;
}
}

public class Dog extends Animal
{
private boolean vacinated;
private boolean rabid;
private Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
{
super(name, legs, eyes);
this.vacinated = vacinated;
this.rabid = rabid;
}
}

public class Bulldog extends Dog
{
private String breedtype;
public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
{
super(vacinated, rabid, name, legs, eyes);
this.breedtype = breedtype;
}
}





share|improve this answer


























  • Thank you, I haven't learned about protected yet.

    – Andrew
    Nov 23 '18 at 8:29






  • 1





    You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

    – BackSlash
    Nov 23 '18 at 8:32











  • @BackSlash: why cannot use protected for common properties?

    – htpvl
    Nov 23 '18 at 8:41






  • 1





    @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

    – BackSlash
    Nov 23 '18 at 8:48













  • @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

    – htpvl
    Nov 23 '18 at 8:53





















0














This is a violation of the whole OOP concept. You can have common variables in the parent class as protected variables so that it can be accessed by that class and its children.



Not only variables but also common methods can be defined and implemented in parent class as protected.



Read more here






share|improve this answer































    0














    Here's a simpler example of one of the problems with what you're doing:



    class A {
    String a;

    A(String a) { this.a = a; }
    }

    class B extends A {
    String a;

    A(String a) { super(a); }
    }


    This code will probably give results that you don't expect:



    B b = new B("hello");
    System.out.println(b.a); // null


    This may be surprising to you, because it might appear that you initialized a in the constructor of A, via the super(a) call.



    But what's more surprising is that if you cast it to A, it doesn't print null:



    System.out.println(((A) b).a);  // hello


    which looks odd: it prints something different when you treat it as a different type.



    The problem here is that fields are not polymorphic in Java: the a in B hides the a in A. Both fields are there, but when you refer to a on an variable of type B, you get a different field to when you refer to a on a variable of type A.



    For this to work "less confusingly", don't repeat the declaration of a in B:



    class A {
    String a;

    A(String a) { this.a = a; }
    }

    class B extends A {
    A(String a) { super(a); }
    }


    Now:



    B b = new B("hello");
    System.out.println(b.a); // hello
    System.out.println(((A) b).a); // hello





    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53442748%2fis-this-the-only-way-to-make-inherited-objects%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      0














      Your classes are violated OOP. You should define common properties which could be inherited to child classes by protected. It means child classes can access those



      Secondly, the common properties should be defined in parent class and dont need to be re-created in child ones.



      P/S: updated by BlackFlash comment. I will use private modifier for such common properties. In the scope of this question, child classes don't need to access parent's properties.



      Your classes should be changed as follows:



      public class Animal
      {
      private String name;
      private boolean legs;
      private boolean eyes;

      public Animal(String name, boolean legs, boolean eyes)
      {
      this.name = name;
      this.legs = legs;
      this.eyes = eyes;
      }
      }

      public class Dog extends Animal
      {
      private boolean vacinated;
      private boolean rabid;
      private Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
      {
      super(name, legs, eyes);
      this.vacinated = vacinated;
      this.rabid = rabid;
      }
      }

      public class Bulldog extends Dog
      {
      private String breedtype;
      public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
      {
      super(vacinated, rabid, name, legs, eyes);
      this.breedtype = breedtype;
      }
      }





      share|improve this answer


























      • Thank you, I haven't learned about protected yet.

        – Andrew
        Nov 23 '18 at 8:29






      • 1





        You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

        – BackSlash
        Nov 23 '18 at 8:32











      • @BackSlash: why cannot use protected for common properties?

        – htpvl
        Nov 23 '18 at 8:41






      • 1





        @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

        – BackSlash
        Nov 23 '18 at 8:48













      • @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

        – htpvl
        Nov 23 '18 at 8:53


















      0














      Your classes are violated OOP. You should define common properties which could be inherited to child classes by protected. It means child classes can access those



      Secondly, the common properties should be defined in parent class and dont need to be re-created in child ones.



      P/S: updated by BlackFlash comment. I will use private modifier for such common properties. In the scope of this question, child classes don't need to access parent's properties.



      Your classes should be changed as follows:



      public class Animal
      {
      private String name;
      private boolean legs;
      private boolean eyes;

      public Animal(String name, boolean legs, boolean eyes)
      {
      this.name = name;
      this.legs = legs;
      this.eyes = eyes;
      }
      }

      public class Dog extends Animal
      {
      private boolean vacinated;
      private boolean rabid;
      private Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
      {
      super(name, legs, eyes);
      this.vacinated = vacinated;
      this.rabid = rabid;
      }
      }

      public class Bulldog extends Dog
      {
      private String breedtype;
      public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
      {
      super(vacinated, rabid, name, legs, eyes);
      this.breedtype = breedtype;
      }
      }





      share|improve this answer


























      • Thank you, I haven't learned about protected yet.

        – Andrew
        Nov 23 '18 at 8:29






      • 1





        You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

        – BackSlash
        Nov 23 '18 at 8:32











      • @BackSlash: why cannot use protected for common properties?

        – htpvl
        Nov 23 '18 at 8:41






      • 1





        @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

        – BackSlash
        Nov 23 '18 at 8:48













      • @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

        – htpvl
        Nov 23 '18 at 8:53
















      0












      0








      0







      Your classes are violated OOP. You should define common properties which could be inherited to child classes by protected. It means child classes can access those



      Secondly, the common properties should be defined in parent class and dont need to be re-created in child ones.



      P/S: updated by BlackFlash comment. I will use private modifier for such common properties. In the scope of this question, child classes don't need to access parent's properties.



      Your classes should be changed as follows:



      public class Animal
      {
      private String name;
      private boolean legs;
      private boolean eyes;

      public Animal(String name, boolean legs, boolean eyes)
      {
      this.name = name;
      this.legs = legs;
      this.eyes = eyes;
      }
      }

      public class Dog extends Animal
      {
      private boolean vacinated;
      private boolean rabid;
      private Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
      {
      super(name, legs, eyes);
      this.vacinated = vacinated;
      this.rabid = rabid;
      }
      }

      public class Bulldog extends Dog
      {
      private String breedtype;
      public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
      {
      super(vacinated, rabid, name, legs, eyes);
      this.breedtype = breedtype;
      }
      }





      share|improve this answer















      Your classes are violated OOP. You should define common properties which could be inherited to child classes by protected. It means child classes can access those



      Secondly, the common properties should be defined in parent class and dont need to be re-created in child ones.



      P/S: updated by BlackFlash comment. I will use private modifier for such common properties. In the scope of this question, child classes don't need to access parent's properties.



      Your classes should be changed as follows:



      public class Animal
      {
      private String name;
      private boolean legs;
      private boolean eyes;

      public Animal(String name, boolean legs, boolean eyes)
      {
      this.name = name;
      this.legs = legs;
      this.eyes = eyes;
      }
      }

      public class Dog extends Animal
      {
      private boolean vacinated;
      private boolean rabid;
      private Dog(boolean vacinated, boolean rabid, String name, boolean legs, boolean eyes)
      {
      super(name, legs, eyes);
      this.vacinated = vacinated;
      this.rabid = rabid;
      }
      }

      public class Bulldog extends Dog
      {
      private String breedtype;
      public Bulldog(String breedtype, String name, boolean legs, boolean eyes, boolean vacinated, boolean rabid)
      {
      super(vacinated, rabid, name, legs, eyes);
      this.breedtype = breedtype;
      }
      }






      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Nov 23 '18 at 8:56

























      answered Nov 23 '18 at 8:11









      htpvlhtpvl

      63739




      63739













      • Thank you, I haven't learned about protected yet.

        – Andrew
        Nov 23 '18 at 8:29






      • 1





        You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

        – BackSlash
        Nov 23 '18 at 8:32











      • @BackSlash: why cannot use protected for common properties?

        – htpvl
        Nov 23 '18 at 8:41






      • 1





        @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

        – BackSlash
        Nov 23 '18 at 8:48













      • @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

        – htpvl
        Nov 23 '18 at 8:53





















      • Thank you, I haven't learned about protected yet.

        – Andrew
        Nov 23 '18 at 8:29






      • 1





        You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

        – BackSlash
        Nov 23 '18 at 8:32











      • @BackSlash: why cannot use protected for common properties?

        – htpvl
        Nov 23 '18 at 8:41






      • 1





        @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

        – BackSlash
        Nov 23 '18 at 8:48













      • @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

        – htpvl
        Nov 23 '18 at 8:53



















      Thank you, I haven't learned about protected yet.

      – Andrew
      Nov 23 '18 at 8:29





      Thank you, I haven't learned about protected yet.

      – Andrew
      Nov 23 '18 at 8:29




      1




      1





      You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

      – BackSlash
      Nov 23 '18 at 8:32





      You should define common properties which could be inherited to child classes by protected - Actually, you should make them private and define setters and getters instead.

      – BackSlash
      Nov 23 '18 at 8:32













      @BackSlash: why cannot use protected for common properties?

      – htpvl
      Nov 23 '18 at 8:41





      @BackSlash: why cannot use protected for common properties?

      – htpvl
      Nov 23 '18 at 8:41




      1




      1





      @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

      – BackSlash
      Nov 23 '18 at 8:48







      @htpvl For example, because protected variables can be seen by classes inside the same package too. This means that if at some point you need to manipulate those variables or change some behaviour, you'll have to make a breaking change, requiring all the developers who used that variable to update their code. If you make the variable private and write setters/getters, you'll be able to control that variable and make any change to those methods without breaking other code. stackoverflow.com/a/8353371/1759845

      – BackSlash
      Nov 23 '18 at 8:48















      @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

      – htpvl
      Nov 23 '18 at 8:53







      @BackSlash: thanks for this useful info. Actually I don't know protected ones could be accessed in same package. I learnt OOP by C++ and there is no package in that langugae. anw, it is a new learn. tks again.

      – htpvl
      Nov 23 '18 at 8:53















      0














      This is a violation of the whole OOP concept. You can have common variables in the parent class as protected variables so that it can be accessed by that class and its children.



      Not only variables but also common methods can be defined and implemented in parent class as protected.



      Read more here






      share|improve this answer




























        0














        This is a violation of the whole OOP concept. You can have common variables in the parent class as protected variables so that it can be accessed by that class and its children.



        Not only variables but also common methods can be defined and implemented in parent class as protected.



        Read more here






        share|improve this answer


























          0












          0








          0







          This is a violation of the whole OOP concept. You can have common variables in the parent class as protected variables so that it can be accessed by that class and its children.



          Not only variables but also common methods can be defined and implemented in parent class as protected.



          Read more here






          share|improve this answer













          This is a violation of the whole OOP concept. You can have common variables in the parent class as protected variables so that it can be accessed by that class and its children.



          Not only variables but also common methods can be defined and implemented in parent class as protected.



          Read more here







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 23 '18 at 8:16









          Gihan Saranga SiriwardhanaGihan Saranga Siriwardhana

          614424




          614424























              0














              Here's a simpler example of one of the problems with what you're doing:



              class A {
              String a;

              A(String a) { this.a = a; }
              }

              class B extends A {
              String a;

              A(String a) { super(a); }
              }


              This code will probably give results that you don't expect:



              B b = new B("hello");
              System.out.println(b.a); // null


              This may be surprising to you, because it might appear that you initialized a in the constructor of A, via the super(a) call.



              But what's more surprising is that if you cast it to A, it doesn't print null:



              System.out.println(((A) b).a);  // hello


              which looks odd: it prints something different when you treat it as a different type.



              The problem here is that fields are not polymorphic in Java: the a in B hides the a in A. Both fields are there, but when you refer to a on an variable of type B, you get a different field to when you refer to a on a variable of type A.



              For this to work "less confusingly", don't repeat the declaration of a in B:



              class A {
              String a;

              A(String a) { this.a = a; }
              }

              class B extends A {
              A(String a) { super(a); }
              }


              Now:



              B b = new B("hello");
              System.out.println(b.a); // hello
              System.out.println(((A) b).a); // hello





              share|improve this answer




























                0














                Here's a simpler example of one of the problems with what you're doing:



                class A {
                String a;

                A(String a) { this.a = a; }
                }

                class B extends A {
                String a;

                A(String a) { super(a); }
                }


                This code will probably give results that you don't expect:



                B b = new B("hello");
                System.out.println(b.a); // null


                This may be surprising to you, because it might appear that you initialized a in the constructor of A, via the super(a) call.



                But what's more surprising is that if you cast it to A, it doesn't print null:



                System.out.println(((A) b).a);  // hello


                which looks odd: it prints something different when you treat it as a different type.



                The problem here is that fields are not polymorphic in Java: the a in B hides the a in A. Both fields are there, but when you refer to a on an variable of type B, you get a different field to when you refer to a on a variable of type A.



                For this to work "less confusingly", don't repeat the declaration of a in B:



                class A {
                String a;

                A(String a) { this.a = a; }
                }

                class B extends A {
                A(String a) { super(a); }
                }


                Now:



                B b = new B("hello");
                System.out.println(b.a); // hello
                System.out.println(((A) b).a); // hello





                share|improve this answer


























                  0












                  0








                  0







                  Here's a simpler example of one of the problems with what you're doing:



                  class A {
                  String a;

                  A(String a) { this.a = a; }
                  }

                  class B extends A {
                  String a;

                  A(String a) { super(a); }
                  }


                  This code will probably give results that you don't expect:



                  B b = new B("hello");
                  System.out.println(b.a); // null


                  This may be surprising to you, because it might appear that you initialized a in the constructor of A, via the super(a) call.



                  But what's more surprising is that if you cast it to A, it doesn't print null:



                  System.out.println(((A) b).a);  // hello


                  which looks odd: it prints something different when you treat it as a different type.



                  The problem here is that fields are not polymorphic in Java: the a in B hides the a in A. Both fields are there, but when you refer to a on an variable of type B, you get a different field to when you refer to a on a variable of type A.



                  For this to work "less confusingly", don't repeat the declaration of a in B:



                  class A {
                  String a;

                  A(String a) { this.a = a; }
                  }

                  class B extends A {
                  A(String a) { super(a); }
                  }


                  Now:



                  B b = new B("hello");
                  System.out.println(b.a); // hello
                  System.out.println(((A) b).a); // hello





                  share|improve this answer













                  Here's a simpler example of one of the problems with what you're doing:



                  class A {
                  String a;

                  A(String a) { this.a = a; }
                  }

                  class B extends A {
                  String a;

                  A(String a) { super(a); }
                  }


                  This code will probably give results that you don't expect:



                  B b = new B("hello");
                  System.out.println(b.a); // null


                  This may be surprising to you, because it might appear that you initialized a in the constructor of A, via the super(a) call.



                  But what's more surprising is that if you cast it to A, it doesn't print null:



                  System.out.println(((A) b).a);  // hello


                  which looks odd: it prints something different when you treat it as a different type.



                  The problem here is that fields are not polymorphic in Java: the a in B hides the a in A. Both fields are there, but when you refer to a on an variable of type B, you get a different field to when you refer to a on a variable of type A.



                  For this to work "less confusingly", don't repeat the declaration of a in B:



                  class A {
                  String a;

                  A(String a) { this.a = a; }
                  }

                  class B extends A {
                  A(String a) { super(a); }
                  }


                  Now:



                  B b = new B("hello");
                  System.out.println(b.a); // hello
                  System.out.println(((A) b).a); // hello






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 23 '18 at 8:46









                  Andy TurnerAndy Turner

                  82.7k982139




                  82.7k982139






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53442748%2fis-this-the-only-way-to-make-inherited-objects%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Costa Masnaga

                      Fotorealismo

                      Sidney Franklin