Should Inherit package-private field or create private one in all subclasses?
2
I have trouble to understand the inheritance of some class fields.
In case of a field that is in all subclasses, but it's different in all of them, how should I code it?
Should I code like this:
class Product {
private String name;
double tax;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Or like this? Which is more correct?
class Product {
private String name;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
private double tax;
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
private double tax;
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Update
following @JB Nizet comment, I altered the way to set the tax value for each subclass:
class Product {
private String name;
private double tax;
Product(String name) {
this.name = name;
}
setTax(double tax) {
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.setTax(0.5);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.setTax(0.05);
}
}
Is this better than the previous two?
java inheritance private
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
add a comment |
2
I have trouble to understand the inheritance of some class fields.
In case of a field that is in all subclasses, but it's different in all of them, how should I code it?
Should I code like this:
class Product {
private String name;
double tax;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Or like this? Which is more correct?
class Product {
private String name;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
private double tax;
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
private double tax;
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Update
following @JB Nizet comment, I altered the way to set the tax value for each subclass:
class Product {
private String name;
private double tax;
Product(String name) {
this.name = name;
}
setTax(double tax) {
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.setTax(0.5);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.setTax(0.05);
}
}
Is this better than the previous two?
java inheritance private
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
You can makeProductsabstract. With this, first approach seems OK, astaxis something common to allis-a Products
– Sid
Nov 24 '18 at 13:04
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
3
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove thesfrom your class names: it makes the code awkward and hard to read.
– JB Nizet
Nov 24 '18 at 13:13
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36
add a comment |
2
2
2
I have trouble to understand the inheritance of some class fields.
In case of a field that is in all subclasses, but it's different in all of them, how should I code it?
Should I code like this:
class Product {
private String name;
double tax;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Or like this? Which is more correct?
class Product {
private String name;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
private double tax;
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
private double tax;
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Update
following @JB Nizet comment, I altered the way to set the tax value for each subclass:
class Product {
private String name;
private double tax;
Product(String name) {
this.name = name;
}
setTax(double tax) {
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.setTax(0.5);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.setTax(0.05);
}
}
Is this better than the previous two?
java inheritance private
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
I have trouble to understand the inheritance of some class fields.
In case of a field that is in all subclasses, but it's different in all of them, how should I code it?
Should I code like this:
class Product {
private String name;
double tax;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Or like this? Which is more correct?
class Product {
private String name;
Product(String name) {
this.name = name;
}
}
class CarProduct extends Product {
private double tax;
CarProduct(String name) {
super(name);
this.tax = 0.2;
}
}
class PharmacyProduct extends Product {
private double tax;
PharmacyProduct(String name) {
super(name);
this.tax = 0.05;
}
}
Update
following @JB Nizet comment, I altered the way to set the tax value for each subclass:
class Product {
private String name;
private double tax;
Product(String name) {
this.name = name;
}
setTax(double tax) {
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name);
this.setTax(0.5);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name);
this.setTax(0.05);
}
}
Is this better than the previous two?
java inheritance private
java inheritance private
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
edited Nov 24 '18 at 13:35
Luís Alves
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
asked Nov 24 '18 at 13:03
Luís AlvesLuís Alves
143314
143314
You can makeProductsabstract. With this, first approach seems OK, astaxis something common to allis-a Products
– Sid
Nov 24 '18 at 13:04
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
3
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove thesfrom your class names: it makes the code awkward and hard to read.
– JB Nizet
Nov 24 '18 at 13:13
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36
add a comment |
You can makeProductsabstract. With this, first approach seems OK, astaxis something common to allis-a Products
– Sid
Nov 24 '18 at 13:04
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
3
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove thesfrom your class names: it makes the code awkward and hard to read.
– JB Nizet
Nov 24 '18 at 13:13
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36
You can make
Products abstract. With this, first approach seems OK, as tax is something common to all is-a Products– Sid
Nov 24 '18 at 13:04
You can make
Products abstract. With this, first approach seems OK, as tax is something common to all is-a Products– Sid
Nov 24 '18 at 13:04
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
3
3
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove the
sfrom your class names: it makes the code awkward and hard to read.– JB Nizet
Nov 24 '18 at 13:13
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove the
sfrom your class names: it makes the code awkward and hard to read.– JB Nizet
Nov 24 '18 at 13:13
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36
add a comment |
1 Answer
1
active
oldest
votes
0
If tax is a common property that all products should have (which makes sense to me, but depends on your exact usecase), I'd keep the tax member in the base class, and have the inheriting classes pass its values to the base constructor:
class Product {
private String name;
double tax;
Product(String name, double tax) {
this.name = name;
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name, 0.2);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name, 0.05);
}
}
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulatetax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.
– Mureinik
Nov 24 '18 at 15:33
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
});
}
});
draft saved
draft discarded
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%2f53458414%2fshould-inherit-package-private-field-or-create-private-one-in-all-subclasses%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
If tax is a common property that all products should have (which makes sense to me, but depends on your exact usecase), I'd keep the tax member in the base class, and have the inheriting classes pass its values to the base constructor:
class Product {
private String name;
double tax;
Product(String name, double tax) {
this.name = name;
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name, 0.2);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name, 0.05);
}
}
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulatetax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.
– Mureinik
Nov 24 '18 at 15:33
add a comment |
0
If tax is a common property that all products should have (which makes sense to me, but depends on your exact usecase), I'd keep the tax member in the base class, and have the inheriting classes pass its values to the base constructor:
class Product {
private String name;
double tax;
Product(String name, double tax) {
this.name = name;
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name, 0.2);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name, 0.05);
}
}
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulatetax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.
– Mureinik
Nov 24 '18 at 15:33
add a comment |
0
0
0
If tax is a common property that all products should have (which makes sense to me, but depends on your exact usecase), I'd keep the tax member in the base class, and have the inheriting classes pass its values to the base constructor:
class Product {
private String name;
double tax;
Product(String name, double tax) {
this.name = name;
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name, 0.2);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name, 0.05);
}
}
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
If tax is a common property that all products should have (which makes sense to me, but depends on your exact usecase), I'd keep the tax member in the base class, and have the inheriting classes pass its values to the base constructor:
class Product {
private String name;
double tax;
Product(String name, double tax) {
this.name = name;
this.tax = tax;
}
}
class CarProduct extends Product {
CarProduct(String name) {
super(name, 0.2);
}
}
class PharmacyProduct extends Product {
PharmacyProduct(String name) {
super(name, 0.05);
}
}
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
answered Nov 24 '18 at 13:22
MureinikMureinik
181k22131200
181k22131200
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulatetax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.
– Mureinik
Nov 24 '18 at 15:33
add a comment |
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulatetax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.
– Mureinik
Nov 24 '18 at 15:33
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
In my user case I want the tax to be fixed for each subclass and not be set by the user. So it as to be set only by the subclass at the instantiate time. I updated my question to show another possible solution.
– Luís Alves
Nov 24 '18 at 13:31
1
1
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
@LuísAlves "to be set only by the subclass at the instantiate time" That's precisely what the above code does.
– user10639668
Nov 24 '18 at 13:42
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
But isn't that the same as my first option?
– Luís Alves
Nov 24 '18 at 13:51
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulate
tax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.– Mureinik
Nov 24 '18 at 15:33
@LuísAlves it's similar, but not quite the same. In your first option, you leave the inheriting classes to directly manipulate
tax. In this way, they don't have direct access to it, and can use getters and setters (admittedly, not shown here) for better encapsulation.– Mureinik
Nov 24 '18 at 15:33
add a comment |
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
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%2f53458414%2fshould-inherit-package-private-field-or-create-private-one-in-all-subclasses%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
You can make
Productsabstract. With this, first approach seems OK, astaxis something common to allis-a Products– Sid
Nov 24 '18 at 13:04
But shouldn't the classes's field be more encapsulated as possible? Even if we have to duplicate code like the declaration of tax in each subclass?
– Luís Alves
Nov 24 '18 at 13:08
3
You shouldn't even have a tax field at all. Just a method getTax() that returns always the same value. Also, does Java have classes named Strings, Integers, Doubles? No, because an instance of the String class is one String. Remove the
sfrom your class names: it makes the code awkward and hard to read.– JB Nizet
Nov 24 '18 at 13:13
You're not following my comment. You still have a useless tax field. You should instead have an abstract getTax() method in the base class, and an implementation that returns a constant in each subclass. No need for any field.
– JB Nizet
Nov 24 '18 at 13:33
Sorry JB Nizet, I'm a noob in OOP. Must study abstraction...
– Luís Alves
Nov 24 '18 at 13:36