Is this the correct use of abstract classes?
$begingroup$
From what I've read, I should use abstract classes when I want to define behavior for a superclass, and I don't want to instantiate the superclass.
So, I'm making a blackjack game in java, and I want a BlackjackDealer class and a BlackjackPlayer class. Would it be okay to make these children of a BlackjackPerson class, since some of the behavior should be the same? An example of behavior that should be the same:
abstract class BlackjackPerson {
protected Card cards;
public void hit(Card c) {
// add c to cards
}
public abstract void displayHand();
// print out hand
}
An example of a BlackjackDealer class, with its own implementation of the displayHand method (since a dealer has 1 card hidden):
class BlackjackDealer extends BlackjackPerson {
public void displayHand() {
for (Card c : cards) {
System.out.println(c);
}
}
}
This is my first time using inheritance, I just want to know if I'm on the right track.
java beginner inheritance
edited 7 hours ago
mdfst13
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
From what I've read, I should use abstract classes when I want to define behavior for a superclass, and I don't want to instantiate the superclass.
So, I'm making a blackjack game in java, and I want a BlackjackDealer class and a BlackjackPlayer class. Would it be okay to make these children of a BlackjackPerson class, since some of the behavior should be the same? An example of behavior that should be the same:
abstract class BlackjackPerson {
protected Card cards;
public void hit(Card c) {
// add c to cards
}
public abstract void displayHand();
// print out hand
}
An example of a BlackjackDealer class, with its own implementation of the displayHand method (since a dealer has 1 card hidden):
class BlackjackDealer extends BlackjackPerson {
public void displayHand() {
for (Card c : cards) {
System.out.println(c);
}
}
}
This is my first time using inheritance, I just want to know if I'm on the right track.
java beginner inheritance
edited 7 hours ago
mdfst13
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
add a comment |
$begingroup$
From what I've read, I should use abstract classes when I want to define behavior for a superclass, and I don't want to instantiate the superclass.
So, I'm making a blackjack game in java, and I want a BlackjackDealer class and a BlackjackPlayer class. Would it be okay to make these children of a BlackjackPerson class, since some of the behavior should be the same? An example of behavior that should be the same:
abstract class BlackjackPerson {
protected Card cards;
public void hit(Card c) {
// add c to cards
}
public abstract void displayHand();
// print out hand
}
An example of a BlackjackDealer class, with its own implementation of the displayHand method (since a dealer has 1 card hidden):
class BlackjackDealer extends BlackjackPerson {
public void displayHand() {
for (Card c : cards) {
System.out.println(c);
}
}
}
This is my first time using inheritance, I just want to know if I'm on the right track.
java beginner inheritance
edited 7 hours ago
mdfst13
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
From what I've read, I should use abstract classes when I want to define behavior for a superclass, and I don't want to instantiate the superclass.
So, I'm making a blackjack game in java, and I want a BlackjackDealer class and a BlackjackPlayer class. Would it be okay to make these children of a BlackjackPerson class, since some of the behavior should be the same? An example of behavior that should be the same:
abstract class BlackjackPerson {
protected Card cards;
public void hit(Card c) {
// add c to cards
}
public abstract void displayHand();
// print out hand
}
An example of a BlackjackDealer class, with its own implementation of the displayHand method (since a dealer has 1 card hidden):
class BlackjackDealer extends BlackjackPerson {
public void displayHand() {
for (Card c : cards) {
System.out.println(c);
}
}
}
This is my first time using inheritance, I just want to know if I'm on the right track.
java beginner inheritance
java beginner inheritance
edited 7 hours ago
mdfst13
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 7 hours ago
mdfst13
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 7 hours ago
mdfst13
17.5k62156
edited 7 hours ago
mdfst13
17.5k62156
edited 7 hours ago
mdfst13
17.5k62156
17.5k62156
asked 9 hours ago
robertrobert
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 9 hours ago
robertrobert
1212
asked 9 hours ago
robertrobert
1212
1212
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
robert is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Look for common functionality
The real power of inheritance comes from the existence of common functionality. In this case, the dealing of cards and the calculation of totals will be common to both players and dealers, and so having both of these in the parent class would be a good choice.
Look for differing functionality
A dealer will have rules on when they hit and when they stay. A player will likely have an amount bet and a chip balance. These would be candidates for inclusion in the child classes.
answered 8 hours ago
Joe CJoe C
795211
$endgroup$
add a comment |
$begingroup$
Congratulations on taking class inheritance with a pinch of salt. This is a tricky part of OOP due to the strong dependency created between the parent and child classes and yet out of an urge for classification many people apply it badly, myself included.
As I understand, you have Blackjack players and one of them is the Dealer. So I would have this simple specialization: BlackjackDealer extends BlackjackPlayer. None of them would be abstract, so sorry if you wanted to put abstract classes to use.
You employ abstract classes when you want to provide partial functionality in a class but it seems that you don't have any to belong to the parent class. This is why I recommend the previous simpler design.
answered 8 hours ago
PiovezanPiovezan
1457
$endgroup$
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having aBlackjackPersonclass doesn't make much sense to me. At least in the naming it should be renamed toBlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.
$endgroup$
– Piovezan
8 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
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: "196"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
robert is a new contributor. Be nice, and check out our Code of Conduct.
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%2fcodereview.stackexchange.com%2fquestions%2f211946%2fis-this-the-correct-use-of-abstract-classes%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Look for common functionality
The real power of inheritance comes from the existence of common functionality. In this case, the dealing of cards and the calculation of totals will be common to both players and dealers, and so having both of these in the parent class would be a good choice.
Look for differing functionality
A dealer will have rules on when they hit and when they stay. A player will likely have an amount bet and a chip balance. These would be candidates for inclusion in the child classes.
answered 8 hours ago
Joe CJoe C
795211
$endgroup$
add a comment |
$begingroup$
Look for common functionality
The real power of inheritance comes from the existence of common functionality. In this case, the dealing of cards and the calculation of totals will be common to both players and dealers, and so having both of these in the parent class would be a good choice.
Look for differing functionality
A dealer will have rules on when they hit and when they stay. A player will likely have an amount bet and a chip balance. These would be candidates for inclusion in the child classes.
answered 8 hours ago
Joe CJoe C
795211
$endgroup$
add a comment |
$begingroup$
Look for common functionality
The real power of inheritance comes from the existence of common functionality. In this case, the dealing of cards and the calculation of totals will be common to both players and dealers, and so having both of these in the parent class would be a good choice.
Look for differing functionality
A dealer will have rules on when they hit and when they stay. A player will likely have an amount bet and a chip balance. These would be candidates for inclusion in the child classes.
answered 8 hours ago
Joe CJoe C
795211
$endgroup$
Look for common functionality
The real power of inheritance comes from the existence of common functionality. In this case, the dealing of cards and the calculation of totals will be common to both players and dealers, and so having both of these in the parent class would be a good choice.
Look for differing functionality
A dealer will have rules on when they hit and when they stay. A player will likely have an amount bet and a chip balance. These would be candidates for inclusion in the child classes.
answered 8 hours ago
Joe CJoe C
795211
answered 8 hours ago
Joe CJoe C
795211
answered 8 hours ago
Joe CJoe C
795211
answered 8 hours ago
Joe CJoe C
795211
795211
add a comment |
add a comment |
$begingroup$
Congratulations on taking class inheritance with a pinch of salt. This is a tricky part of OOP due to the strong dependency created between the parent and child classes and yet out of an urge for classification many people apply it badly, myself included.
As I understand, you have Blackjack players and one of them is the Dealer. So I would have this simple specialization: BlackjackDealer extends BlackjackPlayer. None of them would be abstract, so sorry if you wanted to put abstract classes to use.
You employ abstract classes when you want to provide partial functionality in a class but it seems that you don't have any to belong to the parent class. This is why I recommend the previous simpler design.
answered 8 hours ago
PiovezanPiovezan
1457
$endgroup$
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having aBlackjackPersonclass doesn't make much sense to me. At least in the naming it should be renamed toBlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.
$endgroup$
– Piovezan
8 hours ago
add a comment |
$begingroup$
Congratulations on taking class inheritance with a pinch of salt. This is a tricky part of OOP due to the strong dependency created between the parent and child classes and yet out of an urge for classification many people apply it badly, myself included.
As I understand, you have Blackjack players and one of them is the Dealer. So I would have this simple specialization: BlackjackDealer extends BlackjackPlayer. None of them would be abstract, so sorry if you wanted to put abstract classes to use.
You employ abstract classes when you want to provide partial functionality in a class but it seems that you don't have any to belong to the parent class. This is why I recommend the previous simpler design.
answered 8 hours ago
PiovezanPiovezan
1457
$endgroup$
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having aBlackjackPersonclass doesn't make much sense to me. At least in the naming it should be renamed toBlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.
$endgroup$
– Piovezan
8 hours ago
add a comment |
$begingroup$
Congratulations on taking class inheritance with a pinch of salt. This is a tricky part of OOP due to the strong dependency created between the parent and child classes and yet out of an urge for classification many people apply it badly, myself included.
As I understand, you have Blackjack players and one of them is the Dealer. So I would have this simple specialization: BlackjackDealer extends BlackjackPlayer. None of them would be abstract, so sorry if you wanted to put abstract classes to use.
You employ abstract classes when you want to provide partial functionality in a class but it seems that you don't have any to belong to the parent class. This is why I recommend the previous simpler design.
answered 8 hours ago
PiovezanPiovezan
1457
$endgroup$
Congratulations on taking class inheritance with a pinch of salt. This is a tricky part of OOP due to the strong dependency created between the parent and child classes and yet out of an urge for classification many people apply it badly, myself included.
As I understand, you have Blackjack players and one of them is the Dealer. So I would have this simple specialization: BlackjackDealer extends BlackjackPlayer. None of them would be abstract, so sorry if you wanted to put abstract classes to use.
You employ abstract classes when you want to provide partial functionality in a class but it seems that you don't have any to belong to the parent class. This is why I recommend the previous simpler design.
answered 8 hours ago
PiovezanPiovezan
1457
answered 8 hours ago
PiovezanPiovezan
1457
answered 8 hours ago
PiovezanPiovezan
1457
answered 8 hours ago
PiovezanPiovezan
1457
1457
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having aBlackjackPersonclass doesn't make much sense to me. At least in the naming it should be renamed toBlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.
$endgroup$
– Piovezan
8 hours ago
add a comment |
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having aBlackjackPersonclass doesn't make much sense to me. At least in the naming it should be renamed toBlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.
$endgroup$
– Piovezan
8 hours ago
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
I do see what you mean about just regular inheritance, but aren't there some behaviors that the player needs that the dealer cannot have (like betting per Joe C's example).
$endgroup$
– robert
8 hours ago
$begingroup$
Having a
BlackjackPerson class doesn't make much sense to me. At least in the naming it should be renamed to BlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.$endgroup$
– Piovezan
8 hours ago
$begingroup$
Having a
BlackjackPerson class doesn't make much sense to me. At least in the naming it should be renamed to BlackjackPlayer. Everyone involved are playing a game anyway. Of course, if you have special functionality to a Dealer subclass and some other special to a Player subclass then go ahead and create the abstract class. I'm not familiar with the game so I cannot proceed further. One other thing, don't forget you can have interface inheritance.$endgroup$
– Piovezan
8 hours ago
add a comment |
robert is a new contributor. Be nice, and check out our Code of Conduct.
robert is a new contributor. Be nice, and check out our Code of Conduct.
robert is a new contributor. Be nice, and check out our Code of Conduct.
robert is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- 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.
Use MathJax to format equations. MathJax reference.
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%2fcodereview.stackexchange.com%2fquestions%2f211946%2fis-this-the-correct-use-of-abstract-classes%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
