These were some great answers, guys, thanks. I'll have a lot more the more I write.
I would not use any primitive value type object to represent suit or rank. I would use objects, i.e. a Heart object and a King object. Doing so makes it much easier to do reasoning and comparisons between cards.
I am from the old school and used to start out using symbols, numbers, or strings to represent state. I eventually found out that real objects do a much better job. Rather change my code from some value type of representation to a real object after I found out I need it, I think it is better to just start off that way.
I see the logic of this, but I'm not 100% sure I agree.
The point of having a multiple objects versus a single object would be if the cards behaved differently. But not only do they not behave differently, they only meaning in a larger context. You can't ask the Ace if it's higher or lower than the Jack, for example, because the Ace doesn't know. You can't ask the Ace if it's okay to play itself, because it depends on whether it's Poker, Solitaire, Go Fish, or whatever.
You could say Rules->Deck->Card, because its the rules that determine the relative value of the cards and the composition of the deck. The deck, really, is always going to behave the same. It's just a holder. Its job is to keep track of the cards, shuffle and deal.
Now, if you were making a Magic: The Gathering-type game, yeah, objects for cards--a real hierarchy to boot. And the Deck object should be able to handle that. The rules, however, would determine base play, while deferring to the rule changes specified by the cards.