Trouble implementng an Adapter/Strategy (GoF) design pattern

I have some objects that need various constraints, and each constraint has function for checking the constraint.

So here's a quick detailing of the design I have so far....

Code:

---

public class Constraint
{
    private ConstraintType type;

    public static enum ConstraintType
    {
        type1,
        type2,
        //...
      }
}


public class Constraint1 extends Constraint{ type = Constraint.ConstraintType.whatever}
public class Constraint2 extends Constraint{ type = Constraint.ConstraintType.somethingelse}
etc...


public class ConstrainedObject
{
  private Constraint[] constraints;
}


//the set of constraint checking functions...
public class ConstraintChecker
{
    public boolean method1();
    public boolean method2();
    public boolean method3();
}


//this is sort of the Adapter pattern, but maybe strategy.. ?
public class ConstraintChecker
{
    private ConstraintChecker validator;
 
    public boolean checkConstraints(ConstrainedObject obj)
  {
    //for each constraint in obj...
    switch (constraint.type)
      {
        case typeA:
            return validator.method1(obj);
        case typeB:
            return validator.method2(obj);
        case typeC:
            return validator.method3(obj);
      }
}

---

So, the problem is that I want the Constraint subclasses to be more tightly coupled with the specific constraint type. Would be nice to have it more tightly coupled with the function itself as well, but the functions need to be re-usable also. (like if I have a type that calls method1() and a type calling method2(), I might also want another type that calls both of those methods....

Ideas ?
Thanks

Not 100% sure how validation works, but it seems as though validation is a fixed algorithm for a given constraint? If so, then I suggest putting the constraint checking right in there with the constraint type. To do this, don't have the Constraints be an enum. Instead, have them be an interface (or abstract class if there is good reason to do that).

Code:

---

public interface Constraint {
  public boolean checkConstraint(Constrained constrained);
}

public class Constraint1 implements Constraint {
  public boolean checkConstraint(Constrained constrained) {
...do whatever a Constraint 1 does on the constrained class
    }
}

...

public interface Constrained {
...not sure what goes here, maybe nothing
}

public class ConstrainedInstance implements Constrained {
...
  private Constraint[] constraints;
...

  public boolean checkConstraints() {
    boolean retVal = true;

    for(Constraint c : constraints) {
        retVal &= c.checkConstraint(this);
    }

    return retVal;
  }
}

---

This gets rid of the poorly encapsulated ConstraintChecker, and ties the validation methods tightly to the constraint types. It also keeps the Constraint[] properly hidden by pulling the 'checkConstraints' into the Constrained class. Presumably, Constraints act differently on different Constrained types. I would think hard about what information a Constraint needs from a Constrained, and put accessors for that information in the Constrained interface (then implemented in ConstrainedInstance).

Thank you for responding.
I like the idea of the interface but there's a few problems with that.

Some constraints would be as follows
Numeric, MinLength, MaxLength, ZipCode etc...

These constraints work partly on the ConstrainedObject data and partly on data in the Constraint. When checking constraints the object it passed to the function which grabs the data both from the object and from (one of) its constraint. Puts error messages etc... into the object, and hands it back.

So a ZipCode object might have the ZipCode constraint,
but the ZipCode Constraint just checks for 5 digits, so it would just call the functions coresponding to Numeric,MaxLength(5) and MinLength(5). (Well there will probably be another one Length(x) but you know what I mean....) And when it finaly comes back it has anywhere from 0 to 3 error messages attached to it.

So basically these functions work for various constraints.

Moreover, I am also working on an addition constraint system, where I don't just "attach" constraints to ConstrainedObjects, but I attach Constrained Objects to a Constraint. This is for doubly and tripply constrained objects. In other words dependance between Constrained objects.