Is this the only way to make inherited objects?
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
add a comment |
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
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 multiplename
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 callsuper(...)
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
add a comment |
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
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
java inheritance this parent super
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 multiplename
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 callsuper(...)
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
add a comment |
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 multiplename
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 callsuper(...)
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
add a comment |
3 Answers
3
active
oldest
votes
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;
}
}
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 useprotected
for common properties?
– htpvl
Nov 23 '18 at 8:41
1
@htpvl For example, becauseprotected
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 knowprotected
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
|
show 1 more comment
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
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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;
}
}
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 useprotected
for common properties?
– htpvl
Nov 23 '18 at 8:41
1
@htpvl For example, becauseprotected
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 knowprotected
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
|
show 1 more comment
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;
}
}
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 useprotected
for common properties?
– htpvl
Nov 23 '18 at 8:41
1
@htpvl For example, becauseprotected
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 knowprotected
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
|
show 1 more comment
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;
}
}
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;
}
}
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 useprotected
for common properties?
– htpvl
Nov 23 '18 at 8:41
1
@htpvl For example, becauseprotected
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 knowprotected
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
|
show 1 more comment
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 useprotected
for common properties?
– htpvl
Nov 23 '18 at 8:41
1
@htpvl For example, becauseprotected
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 knowprotected
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
|
show 1 more comment
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
add a comment |
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
add a comment |
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
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
answered Nov 23 '18 at 8:16
Gihan Saranga SiriwardhanaGihan Saranga Siriwardhana
614424
614424
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Nov 23 '18 at 8:46
Andy TurnerAndy Turner
82.7k982139
82.7k982139
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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