Is this the correct use of abstract classes?












4












$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.










share|improve this question









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$

















    4












    $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.










    share|improve this question









    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$















      4












      4








      4





      $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.










      share|improve this question









      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






      share|improve this question









      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.











      share|improve this question









      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.









      share|improve this question




      share|improve this question








      edited 5 hours ago









      mdfst13

      17.5k62156




      17.5k62156






      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 6 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.






















          2 Answers
          2






          active

          oldest

          votes


















          1












          $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.






          share|improve this answer









          $endgroup$





















            1












            $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.






            share|improve this answer









            $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
              6 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
              6 hours ago













            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.










            draft saved

            draft discarded


















            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









            1












            $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.






            share|improve this answer









            $endgroup$


















              1












              $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.






              share|improve this answer









              $endgroup$
















                1












                1








                1





                $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.






                share|improve this answer









                $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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 6 hours ago









                Joe CJoe C

                775211




                775211

























                    1












                    $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.






                    share|improve this answer









                    $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
                      6 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
                      6 hours ago


















                    1












                    $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.






                    share|improve this answer









                    $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
                      6 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
                      6 hours ago
















                    1












                    1








                    1





                    $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.






                    share|improve this answer









                    $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.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 6 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
                      6 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
                      6 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
                      6 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
                      6 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
                    6 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
                    6 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
                    6 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
                    6 hours ago












                    robert is a new contributor. Be nice, and check out our Code of Conduct.










                    draft saved

                    draft discarded


















                    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.




                    draft saved


                    draft discarded














                    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





















































                    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

                    A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

                    Calculate evaluation metrics using cross_val_predict sklearn

                    Insert data from modal to MySQL (multiple modal on website)