Design Class - How 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.

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.