Results 1 to 9 of 9
  1. #1
    BustTheCode is offline Member
    Join Date
    Sep 2013
    Posts
    11
    Rep Power
    0

    Default Trying to figure out the the best way to organize classes for Uno card game

    I'm currently taking a computer program design class which has done a lot for my understanding of how to organize classes, but isn't giving me challenging enough assignments and I don't believe it's going to be covering interfaces and abstract classes, which is a shame. So I've been digging into these topics myself and decided to work on my own program (an Uno game program) that would utilize everything we've been learning and give me some practice with GUIs.

    I'm finding that there are still gaps in my understanding and areas that don't seem readily intuitive yet, so alas I'm here asking the experts :).

    I've been trying to figure out the best way to summarize this information for you guys, so I'm really sorry if it's too lengthy.

    My current plan:

    have an abstract UnoCard class that determines the basic properties/methods common to all cards. Create a class for each card type extending from UnoCard, which would be - the generic card (number and color), action cards (skip, reverse, draw two), and special cards (wild, wild draw four, and blank).

    Two enums, one for color, one for rank (which includes the numbers, as well as the action and special card ranks (reverse, wild, exc.) ).

    A deck class would have an ArrayList <UnoCard> property and it's constructor would initialize a fresh deck.

    A hand class that also has an ArrayList <UnoCards> where it gets said cards from the deck class.

    A discard pile class, which contains the cards discarded and the current card in play.

    A "board" class (haven't figured out a better name for it yet) which would determine/keep track of the number of players/hands, the turn order, the locations of the cards, and the winning condition.

    Area of confusion and concern I'm having:

    From what I've read, I want to avoid circular dependency. So if that's the case, when a card type effects the state of a "hand" or the turn order or really anything else, then in what class do I place the method(s) that effect that? If I place it in the specific card class, wouldn't that create a circular dependency? So would it be better then to have the hand class figure out what can be done with a specific card and what that specific card effects (which wouldn't that hinder the cohesion of the class?)?

    I was also thinking a possible solution might be to have the non-generic card types contain methods that return values as apposed to manipulating higher level classes, such as a boolean drawCards which returns true if cards need to be drawn, false otherwise (same for skip, reverse, exc.).Then maybe the board class can determine what to do if those values are true or false (which actually seems more convoluted since only one value would be allowed to be true at any given time).

    The other solution I was considering is to have a single UnoCardRules class, which serves the sole function of providing methods to determine the effects of each card, that way each card class can only worry about defining the card's state.

    Sorry for my convoluted post, I hope I'm not over thinking this, I just really want to have a strong grasp on program design and don't have the experience yet to know the pitfalls.

    Thanks to anyone who read that, and any feedback!
    Last edited by BustTheCode; 03-20-2014 at 09:32 AM.

  2. #2
    typedef is offline Member
    Join Date
    Feb 2014
    Posts
    52
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    First and foremost, I'm not a pro I'm just a beginner giving his 2 cents on your problem and hoping some of this is helpful to you.

    The unifying factor here is an interface in my opinion. You cut off ties to progressive circular dependencies in an ongoing project by a establishing an interface that allow classes to communicate to each other without having to know about each other. Personally as this is a project your doing on the side for your own learning benefit I'd start with something simpler. I'd start with games that revolve around the 52 card deck like go fish or blackjack and such. This way you have a class that you can recycle for more games than one. Easier games also mean you can experiment with making more features such as, saving the game to a file.
    Back to UNO though, I'd establish an interface:

    public interface CardManagementProperties
    {
    public UnoCard giveCard(CardManagementProperties cm);
    public void getCard();
    }

    Your card handlers (deck, hand, pile) could then implement this and the way cards are given and received is up to the class independent of hard coded dependencies.

    I really suggest you try 52 card deck games first though as you can raise and lower project ideas depending on how it turns out for you.
    Sorry, if this didn't really answer your question as I only really thought about this for about 10 mins plus its late for me right now but if you'd like to discuss it further or have any questions ask away.

  3. #3
    BustTheCode is offline Member
    Join Date
    Sep 2013
    Posts
    11
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    Wow thank you so much for that! I had actually sat down with my class set up for a few more hours since I posted my thread (not including the time I spent THINKING about it, which has been non-stop) and I had a sudden realization of how these classes are actually interacting and what the card classes actually need to do. It's much less complex than I initially thought, as really the major problems were solved once I realized all that was needed was a few specific methods to compare the properties of cards against each other with special comparisons for wild cards. I decided that if a SkipCard means to skip, it's the role of the class in charge of turn order to ensure that a SkipCard skips a person while it's the role of the SkipCard to simply exist as an entity and be compared (I hope my logic isn't flawed).

    But from what you just said about interfaces, I'm gob smacked. That's such an obvious and streamlined use for them that I can't figure out how I missed this purpose while looking up tutorials and youtube videos! Tons of concepts just came together in my brain that now give me a better footing on what to research next, so thank you! Gawd I love that giddy adrenaline rush of understanding that happens with programming.

    It seems like the internet isn't doing a good job of really breaking down the details and concepts for me in a way that allows me to connect all the dots. Are there any good books or web sources that really get into explaining the theory behind the practice that can be recommended? I just picked up both volumes of core java, as well as effective java which seem promising, but core java feels like it summarizes a bit too much (it's probably my learning style though, which is strongly visual).

    Also, with the card game, I actually did start with that haha. It seemed pretty straight forward. I cranked an effective card game program out in about 45 minutes (granted it was text based and the "game" part was just comparing two cards to see which was larger... so maybe I will revisit this). I actually jumped on Uno because I heard that this same class I'm in used to have Uno as their giant, one and only semester long project. They've apparently dumbed the class down significantly (it's even on a 20 point scale now, meaning I can make an A by getting an 80% in the class) which irks me to no end, so I'm kinda doing it as a "psh, I'll show you jerks what I'm capable of!" thing haha.

  4. #4
    datta is offline Member
    Join Date
    Mar 2014
    Posts
    1
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    thats the good option.

  5. #5
    BustTheCode is offline Member
    Join Date
    Sep 2013
    Posts
    11
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    Quote Originally Posted by datta View Post
    thats the good option.
    Sorry I'm a bit confused, were you referring to typedef's suggestion or one of my attempts at a solution? Either way I'm reading more on interfaces as we speak as I'm 90% sure that'll be the solution for keeping of track of what cards are where when the deck is split among two+ classes.

  6. #6
    typedef is offline Member
    Join Date
    Feb 2014
    Posts
    52
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    Quote Originally Posted by BustTheCode View Post
    Wow thank you so much for that! I had actually sat down with my class set up for a few more hours since I posted my thr (not including the time I spent THINKING about it, which has been non-stop) and I had a sudden realization of how these classes are actually interacting and what the card classes actually need to do. It's much less complex than I initially thought, as really the major problems were solved once I realized all that was needed was a few specific methods to compare the properties of cards against each other with special comparisons for wild cards. I decided that if a SkipCard means to skip, it's the role of the class in charge of turn order to ensure that a SkipCard skips a person while it's the role of the SkipCard to simply exist as an entity and be compared (I hope my logic isn't flawed).

    But from what you just said about interfaces, I'm gob smacked. That's such an obvious and streamlined use for them that I can't figure out how I missed this purpose while looking up tutorials and youtube videos! Tons of concepts just came together in my brain that now give me a better footing on what to research next, so thank you! Gawd I love that giddy adrenaline rush of understanding that happens with programming.

    It seems like the internet isn't doing a good job of really breaking down the details and concepts for me in a way that allows me to connect all the dots. Are there any good books or web sources that really get into explaining the theory behind the practice that can be recommended? I just picked up both volumes of core java, as well as effective java which seem promising, but core java feels like it summarizes a bit too much (it's probably my learning style though, which is strongly visual).

    Also, with the card game, I actually did start with that haha. It seemed pretty straight forward. I cranked an effective card game program out in about 45 minutes (granted it was text based and the "game" part was just comparing two cards to see which was larger... so maybe I will revisit this). I actually jumped on Uno because I heard that this same class I'm in used to have Uno as their giant, one and only semester long project. They've apparently dumbed the class down significantly (it's even on a 20 point scale now, meaning I can make an A by getting an 80% in the class) which irks me to no end, so I'm kinda doing it as a "psh, I'll show you jerks what I'm capable of!" thing haha.
    Unfortunately this is going to be a 2 part post that I will complete tomorrow because 1) I'm typing on a virtual tablet keyboard and 2) I'm about to go to bed.
    Thought it was crucial that I give another opinion on the design. One of the goals of OOP is reusability. You stated you'd make the skip card in charge of skipping but in my opinion it should be the class that acts to unify the components that should dictate the skipping. This is your framework for your game. You should make the card handlers give and accept generic tasks such that the components can be used in the long run for multiple games. This is why I suggested the 52 card games. When you make go fish the deck, hand, and card class can be used for both games without making new classes you merely must make a new game framework. This way your building class tools and not hard coding.
    Another reason for this is because later on you can extend the classes for more functionality through inheritance.
    Hope that made sense will elaborate\add more tomorrow.

  7. #7
    BustTheCode is offline Member
    Join Date
    Sep 2013
    Posts
    11
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    Your overall message did/does make sense, that being: I've got much more to gain and learn by spending more time with simpler/expandable problems than I do diving into problems that are just over my head at this point. Fair enough, I can go back to standard playing cards as my main polished project. Though I'm not sure I can stop with the Uno all together at this point now that it's gotten under my skin.

    Your message in regards to my program design - I believe that makes sense to me. Though to clarify some of my confusion - in my previous post, I intended to indicate that the SkipCard class would simply define the current state of the SkipCard while the class in charge of turn orders (which would be the class that organizes the objects into a game with rules) would figure out how to impliment a SkipCard. But something tells me this isn't the complete picture of what you meant when you said "make the card handlers give and accept generic tasks such that the components can be used in the long run for multiple games."

    I greatly appreciate the help and insight so far (despite sleep deprivation) and will definitely check back.

  8. #8
    typedef is offline Member
    Join Date
    Feb 2014
    Posts
    52
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    "Make the card handlers give and accept generic tasks such that the components can be used in the long run for multiple games."
    What I mean by this is that the cards should abide by a strict communication code. In this case the interface as stated before. The deck, hand, and card class should be simple it is the game's rules that should do the heavy lifting as much of this is not generic - it is only applicable to one game.
    State is a very broad concept in design but in this case it can be very specific. For example, if I'm making a Remote class I can make a remote that has an on button for an interface TV. If I make my remote turn on a Samsung TV and give it the responsibilities for triggering other features that the TV implements when turning on I violate the interface of a Remote turning on a TV object implementing the TV interface. In code, implementing features that do not abide by the interface end up delegating the tasks to the wrong class - the class that violated the interface, in this case the Remote. If this doesn't change your method signature to a concrete specific class in the long run of a project you'll have multiple indirect dependencies within the violating method at best.
    The best thing to do is not violate the interface. Implement a type of call response system. When I turn on the TV I send data to the TV through my pushOn() method of my Remote interface. The class implementing Remote say SamsungRemote might have access to the TV through an instance variable such as registering the TV to the remote through a method registerValidTVs(TV tele) or something. Notice the parameter is TV which is an interface that will reference a concrete TV implementing TV and is not a concrete TV like SamsungTV. The big point here though is not how Remote has access to the class implementing TV but how Remote will implement the pushOn() method. It will take the necessary data for turning on the TV by a remote and pass it to a TV that implements a TV interface. The TV interface will already have a turnOn() method but it may also specify a turnOnByRemote(). That method may have multiple specifications depending on the concrete class that implements the interface. A OffBrandTV might just call the TV's interface implemented method turnOn() immediately. On the other hand, a SamsungTV might be a smart TV that first initializes connection to the internet through one of its concrete methods then might call turnOn(). The point is Remote knows nothing about how the TV turns on - its only responsibility is to alert TV to turn on by giving turnOn dat. What the TV does to that data is independent of the Remote.

    How does this relate to UNO? card games? anything? It relates because its essential that you keep a call and response mechanism in tact such that you can reuse as much as possible. The state of a card can be generic. For example flipped can be true or false. This is a state of information that is useful to a framework. The framework can check the card for being flipped or not. On the other hand a state for a reverse card can be left or right depending on which way the game is currently playing. This on the other hand is not generic nor independent. This would require you to obtain data from the framework to give out more data from a generic component. This establishes an unnecessary dependency in my personal opinion. It would better to obtain the value of the card. Since the card is not a 0-9 it is a "F" or "Flip" or "Flip card" or 15 which is a code that represents flip card. I would then get this value through the card interface that implements a getValue() method.
    If you wish to extend the functionality of a interface extend the interface instead of taxing the concrete classes with more dependencies. For example, a card class has two instance variables value and suit. It has methods for obtaining and manipulating these values. But let's say we have a special card later on that provides more data, specialEffect. We can extend our card interface to have methods for manipulating this new instance variable specialEffect. We then make classes that implement this interface such as TroubleCard or UnoCard. This specialEffect still gives data and doesn't have to depend on other classes.
    I guess my overall point is when you have to communicate with a dependency ask yourself is this dependency common amongst other types? If it is make an interface and communicates with it by giving data and avoid having to receive back the interfacee's data. If the dependency is not common and is very specific try to make it more broad. Make/think of a broad interface and subinterface those interfaces or better than that try to find a work around as a super specific interface might lead to little to no reuse.
    This is what goes through my mind when I'm designing with dependencies. As I've stated earlier I'm just a beginner so I might be wrong in some of my thinking.
    Some of this might also not make sense, sorry if it doesn't I just kinda started writing and then it turned out to be a perhaps a full out continuous unproofed rant. Let me know if something didn't make sense and I'll try to clarify it as best as I can. Hope some of this does help. As for a book on design patterns I recommend this one: http://www.uml.org.cn/c%2B%2B/pdf/DesignPatterns.pdf which I got off this website: 5 Best Design Pattern Books you must read as a Software Developer | FromDev
    Unfortunately the book is in c++ (which I understand) and some in SmallTalk (an old language I definitely don't understand). What's nice though is I found this website: Design Patterns | Object Oriented Design which has implementations of the design patterns in Java code. It's got nice diagrams and if you'd like to make your own I'd recommend the super simple program by Cay Horstmann (Core Java book you listed above -- currently reading vol 2 and I love the book): Violet UML Editor : easy to use, completely free

  9. #9
    BustTheCode is offline Member
    Join Date
    Sep 2013
    Posts
    11
    Rep Power
    0

    Default Re: Trying to figure out the the best way to organize classes for Uno card game

    Wow thank you again! I've read over your thorough response twice and been reading and re-reading basic guides on java interfaces and so many things are making more sense to me now. Before, I was having a difficult time seeing a need for an interface as a lone programmer since my thinking was, "well I trust me to make the correct methods, why would I need to force myself to do it with more overhead?" From poking around the internet, it seems this is a really common early pitfall into this concept and I think this has to do with 1) Interfaces are first summarized/explained purely through their role as a "contract," while the powerful implications of a contract get glossed over in the last paragraph. Very few of the interface tutorials I found online even mention decoupling. 2) The incredible benefits of interfaces aren't exactly obvious until you are actually working on a complicated enough project. And 3) Even for OOP I think this really is one of the more abstract, non black-or-white concepts, at least that I've come accross so far. There aren't a rigid set of mental checks and guidelines you can do that will lead you to the proper solution every time, at least compared to the relatively simple process of seeing if a class needs to inherit, or is it an aggregate relationship. To judge the value of an interface seems like it's a few levels of complexity above simple class to class relationships, and requires forethought, investigation, and understanding of all class relationships.

    I am unbelievably tired so I wont be able to provide the response your analysis deserves tonight, but I will say that I feel like the use of an interface also solves the concerns I was having over my deck class passing cards around to other classes with nothing keeping track of them all. I was also thinking I probably need to re-frame how I look at it. Instead of a "deck" class, which passes cards to "hands" and a "discard" pile, what is really happening is one large stack of cards is splitting itself up into smaller stacks of cards. It's "almost" describing inheritance, so maybe it's describing an implementation instead, which would provide a one stop place for everything to communicate, and if my logic is correct, would mean the issue of keeping track of all individual cards gets taken care.

    But yeah, I'll read over again your response over the weekend, and start applying this stuff to my card classes and see if I'm having any more confusion.

    Thank you so much!

Similar Threads

  1. Card Game
    By HarleyRowland in forum New To Java
    Replies: 7
    Last Post: 02-05-2013, 01:44 AM
  2. Creating a Card Game
    By Kidd91 in forum New To Java
    Replies: 1
    Last Post: 12-24-2010, 03:25 PM
  3. Card Game
    By abby0910 in forum New To Java
    Replies: 1
    Last Post: 07-24-2010, 01:38 AM
  4. please help me with this card game
    By noobinoo in forum New To Java
    Replies: 13
    Last Post: 03-28-2010, 03:07 PM
  5. Problem to organize my code in classes
    By ze snow in forum New To Java
    Replies: 4
    Last Post: 02-23-2010, 05:28 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •