# How to program for constraints/rules

First the background, during interviews in the past, many times I have been asked to design some or other variation of card game as programming puzzle, and I have tried to design it in OO way, but I have never been satisfied with my solutions. However it was not until recently that I realized that I had been approaching the problem from the wrong direction. Specifically I was trying to solve the problem by modeling individual card as an object.

Problem with this is individual cards don't have any non-trivial intrinsic behavior and therefore are not suitable (or primary) candidate as objects. What is interesting and important about cards are rules and constraints, such as there could be only four suits, or only thirteen cards in each suit. Of course, then there are any number of rules for games.

So my questions are

1. Are there any idioms/constructs/patterns to program for rules & constraints.
2. How many in 1 can be applied in conjunction with OO paradigm.
-
I'm not convinced that just because individual cards don't have (as you claim) non-trivial behavior that they cannot be modeled effectively as individual objects. There are programming languages that model everything as an object, even primitive numbers. And there are many examples of lists of trivial objects in programming (which is what your card deck is). – Robert Harvey Jan 1 '11 at 20:59
To put it another way, if you don't store the suit and rank of each card in an object, where will you store it? You can also store the image of each card in the object itself. Seems like a very natural way to do it to me. – Robert Harvey Jan 1 '11 at 21:00
@Robert of course I didn't mean to say you couldn't model individual cards as objects, what I meant was such modelling doesn't address the crux of the problem which are rules and constraints. Even deck can be modeled in terms of these rules and constraints – Gaurav Jan 1 '11 at 21:02
@Gaurav: modelling cards as objects sounds like a fine way to treat the cards themselves, but you’re quite right that that doesn’t complete the job of modelling a card game. A card game is a separate thing from the cards used to play it (hence playing cards are used to play lots of different games). – Paul D. Waite Jul 31 '12 at 16:47
You are looking for SMT or CSP solvers. Look at existing implementations. – user Sep 13 '13 at 7:58

These guidelines/idioms are called Constrained Programming, which is not easy thing to do. It is used for modeling and solving combinatorial problems (NP-hard, NP-complete). I can recommend you one book - Principles of Constraint Programming. This book is one of the best books on the subject, but, still, after reading it you still won't be able to apply it in practice.
But, you will be able to do that by getting familiar yourself with Gecode - a toolkit for developing constraint-based systems and applications. Gecode provides a constraint solver with state-of-the-art performance while being modular and extensible.
I can say that this subject is very interesting, I'd say one of the best courses I had during my studies. Btw, the author of Gecode, was my professor, so I was very lucky :)

-

I tend to find this type of problem when using poco or dto 'dumb' objects.

In which case, I've found my code using service type objects, usually separated by layers such as presentation / logic / persistence. Each layer serves up (or consumes) a (set) of dto's.

Anther approach I like is to use smart containers. I create a container (such as a specialized list) that enforces rules. So I might have a deck that has 52 cards, and a pokerHand that has 5 cards, where a pokerHand may have 'isFullHouse' to model what a full house is. A PokerGame would have 1 deck, and 4 poker hands. The card object stays trivial (or dumb), while the containers are more behavior orientated (smart).

-
@DereKK can you give some link/ref for service type object. Thanks :-) – Gaurav Jan 1 '11 at 21:52
@Gaurav Since DereKK didn't follow up I'll explain the way I've been taught service objects in the context of DDD. Basically they contain the business logic of an application and form a service layer on top of the data layer. They're usually programmed against interfaces to allow for some swapping in case of implementation changes. Domain services contain methods which are related to corresponding classes in the domain model. – James Poulson May 14 '12 at 7:45