Hi Evan

Actually, OOA/OOD/OOP is based on the concept of simulating real-world objects. There should be two classes - a deck class and a card class.

Regardless of religious beliefs a deck of cards is a collection of physical objects. It could just as easily be a stack of Hollerith punch-cards.

The deck class can be subclassed depending on the card game. It should know how many cards and what class of card - Tarot / playing cards / Hollerith.

The original poster specified a deck of cards. The design should meet the natural/regular usage of the items in the real-world. I believe this does. The dealer can instantiate a deck depending on the game being "played".

The dealer must be modelled without consideration of the deck and in this case would not be modelled as it was not part of the original request. The cards and the deck must be modelled with consideration of the dealer. Otherwise you may create a deck that is too small for the dealer to use/see.
Cards are designed to be used by human hands. Card dispensing machinery are designed to use cards.

The deck could provide a card to the dealer, regardless of type of dealer. The deck would then remove that card.

Card superclass.
Properties: height,width,thickness,back image,front image
Methods: get/set for the above.

Playing card subclass.
Properties: facevalue, suit
Methods: get/set for those properties.

Deck class.
Properties: type, collection of cards
Methods: public: takecard(position), putback(position)

That's all I can think of for now. I believe that should allow the cards to by shuffled, used in card tricks, etc.

As to modelling the coop and/or the chicken, the chicken must be modelled without consideration of the coop, but the coop cannot be modelled without consideration of the chicken.

Soup should sound like sour. Soop should sound like coop. ;)

>>I'm a big believer that if your a good coder in a different language you'll be a good coder in any language - because it's about the logic and the rest is just syntax. So I was looking for an OOP question that didn't rely on FoxPro knowledge and came up with. Can you describe a deck of cards as objects? Telling me what classes you would create and what properties and methods you would put in each class. To this date only 1 person has ever given me a good response on this question. Is it too tuff of a question or is it a bad question?
>
>There are a number of ways to do this, depending on what you are going to do the the objects, or which kind of problem you will be solving. which of these would you consider a good response?
>
>SOLUTION 1:
>- class called card
>- card has two properities face (2-A) and suit
>- to represent a card, instantiate the class into 52 objects then assign the face and suit
>
>SOLUTION 2:
>- have a class called deck
>- have class called card from solution 1, with the same properties
>- have a method called create() on deck that creates a collection of card objects, 1 for each of the 52 cards
>
>SOLUTION 3:
>- a class called card
>- card has 4 methods, GetSuit(), SetSuit(), GetFace(), SetFace()
>- have methods instead of properties, means that the object doesn't have to maintain state, which may be appropriate in some cases